Backend Troubleshooting

Java’s LocalDateTime and PostgreSQL’s time types “aren’t talking about the same kind of time.” First, get clear on PostgreSQL’s two time types TIMESTAMP → without time zone, just a bare time "2026-06-25 10:00:00" TIMESTAMPTZ → with time zone, stored internally as UTC, converted to the session time zone on query On the Java side LocalDateTime → no concept of a time zone, just a bare time ZonedDateTime → with time zone OffsetDateTime → with an offset (e.g. +08:00) Instant → a UTC timestamp Why the error happens The PostgreSQL JDBC driver (especially newer versions 42.x+) is very strict about type matching: ...

In the Spring Boot ecosystem, the annotations changed a great deal between Swagger 2.0 (typically using the Springfox dependency) and Swagger 3.0 (typically using the Springdoc-openapi dependency, based on the OpenAPI 3 spec). Below is a complete correspondence table of the common annotations in Swagger 2.0 vs. Swagger 3.0 (OpenAPI 3): 1. Core annotation correspondence table Description Swagger 2.0 annotation (io.swagger.annotations) Swagger 3.0 annotation (io.swagger.v3.oas.annotations) Notes Mark a controller class @Api(tags = "User API") @Tag(name = "User API") 3.0 removed the description attribute; use name uniformly Mark an API method @ApiOperation(value = "Get user") @Operation(summary = "Get user") In 3.0 value became summary Request/entity class @ApiModel(value = "User object") @Schema(description = "User object") 3.0 greatly simplified this; use @Schema uniformly Entity class property @ApiModelProperty(value = "Name") @Schema(description = "Name") As above, merged into @Schema Ignore a property @ApiModelProperty(hidden = true) @Schema(hidden = true) Ignore a whole class/method @ApiIgnore @Hidden For endpoints or parameters you don’t want exposed in docs 2. Request-parameter annotation correspondence table For method parameters (URL path parameters, query parameters, etc.), 3.0 introduced a more structured configuration: ...

Issue source: spring-cloud-alibaba#3931 Affected versions: spring-cloud-alibaba 2023.0.1.3+ 1. Problem Description In Spring Cloud Alibaba 2023.X, placing Nacos config (including extension-configs, shared-configs, etc.) in bootstrap.yml / bootstrap.properties causes the config center’s content to fail to load properly, even though the logs show the bootstrap file itself was read. Moving the same config to application.yml makes everything work again. 2. Root Cause flowchart TD A[bootstrap.yml is read] --> B{SCA version check} B -- 2023.0.1.2 and earlier --> C[✅ Nacos config center loads normally] B -- 2023.0.1.3 and later --> D[❌ extension-configs / shared-configs fail] D --> E[Root cause: SCA 2023.0.1.3 changed the config-load priority mechanism] E --> F[Nacos PropertySource registered in the bootstrap phase is overwritten or discarded by later steps] In short: SCA 2023.0.1.3 made a backward-incompatible internal change, causing the Nacos extension config in bootstrap.yml to be “dropped” in the loading chain, while config in application.yml takes the new path and is unaffected. ...