Recurring Defect Classes

A controller that returns ResponseEntity<StreamingResponseBody> — or an SseEmitter or ResponseBodyEmitter — commits the status line and headers before the body is written. The body is produced on an async dispatch.

Spring Security re-evaluates the request on that async dispatch. The request-thread SecurityContext does not propagate to it, so a method-level @PreAuthorize fails there. ExceptionTranslationFilter then tries to render an error response, finds the response already committed, and throws instead of rendering. The async dispatch and the subsequent error dispatch each raise it, so the lines come in pairs.

A successful request log line, immediately followed by error-level lines about a request that was in fact served:

The response itself is correct and complete: the status is 200, the headers are well formed, and the body is not truncated.

The lines are cosmetic for the caller and expensive for everyone else. Anything that alerts on level="ERROR" fires on ordinary, successful use of the endpoint — and fires hardest when the endpoint is used most, which is precisely when a real signal needs to be visible.

Angular excludes disabled controls from FormGroup.value. A component that disables a control for presentation reasons — because another field is meant to derive it, or because it is read-only in this mode — and then reads .value to build a request emits an object with those keys absent, not null.

A field the operator can plainly see filled in — because they typed it, or because a lookup populated it — is silently dropped from the request. The form is valid, the save succeeds, and the value is simply not there afterwards. Where the component is a ControlValueAccessor, the collapse happens at the boundary between child and parent, so neither side looks wrong in isolation.

A JPA association is declared mandatory while the underlying foreign-key column still accepts NULL:

Rows created through the REST API are safe, because the DTO carries its own @NotNull. Rows created by direct SQL are not. Any such row is one Hibernate cannot materialise, permanently.

Every symptom points somewhere other than the real cause:

A controller annotated @Profile("stub") serves endpoints only when that profile is active, and stub is reachable only through the dev profile group. Stage and production run the prod posture, where the bean is never created, so every endpoint it serves returns 404. See Spring Bootstrap for how profiles select posture rather than environment.

A screen that works perfectly in development and fails only where it matters. Two shapes have occurred:

The Maven build does not enable the -parameters compiler flag anywhere in the POM hierarchy. The root parent is a standalone POM that does not inherit from spring-boot-starter-parent, so the <parameters>true</parameters> that Spring Boot applications normally receive by inheritance was never picked up.

Spring Framework 6.1 removed the bytecode debug-information fallback for discovering parameter names, and the services run a later version than that. There is no fallback. A binding that omits its name therefore has no name at all at runtime.

HTTP 500 on every call to the endpoint, with:

Binding throws before handler logic runs, so an otherwise trivially correct happy-path endpoint returns 500 for every request.

The failure is runtime-only, and only for un-named bindings on endpoints actually exercised over HTTP. Most controllers already name their bindings, so they are safe and the class stays invisible. Service-layer integration tests never exercise HTTP binding at all — so a controller with bare bindings compiles, passes its suite, ships green, and returns 500 in production.

With both the OpenTelemetry agent’s Logback instrumentation and an explicitly declared OpenTelemetryAppender active, every statement is exported twice. The obvious fix is the property that disables the agent’s capture.

That same property name also gates the OpenTelemetry Spring Boot starter’s OpenTelemetryAppender.install() call, which Spring resolves from the environment — including system properties. Setting it as a JVM flag or environment variable therefore disables both: the duplicate is gone, and so is the appender’s SDK.

Two distinct symptoms, one on either side of the naive fix:

The full configuration, including the conformance checklist, is in OpenTelemetry Configuration.

Generated API clients restrict their output with an explicit modelsToGenerate allow-list. The generator honours that list literally: when a listed model `$ref`s an unlisted one, it still emits the reference — into the type map, the docblocks and the setter hints — and never emits the class.

Nothing objects. Generation succeeds, dependency installation succeeds, and a syntax check passes.

The symptom depends entirely on how the target language resolves types:

The dynamic case is the damaging one, because the failure lands on the deserialisation of a successful response. The remote call applied; the client throws while reading the reply; the operator is told the operation may not have happened.

Closure is a property of the specification plus the allow-list, so it is checkable statically before anything is published. Gate that check in the generation workflow ahead of the commit step. When adding a resource, do not hand-pick the models it needs — add the obvious ones and let the closure computation find the transitive set.

The mechanism, the detection script, and the CI wiring are documented in OpenAPI Contract Flow.

Client regeneration is triggered by a repository dispatch from the service whose specification changed. Nothing watches whether the triggered run succeeded. The dispatching pipeline goes green either way — it only records that it fired the event — and the package registry keeps serving the last version that published successfully.

The observed failure mode is an expired credential taking out the very first step of the triggered workflow:

Every run after that fails identically, forever, with nothing downstream reporting it.

A DTO that plainly exists in the service is absent from the published client. Consumers compile against a contract that has not moved for months, and the gap is invisible from the service side.

Before assuming a DTO is available to a consumer, check the client repository directly:

A secret listing shows each secret’s last-updated date without its value, which is how a long-expired token is spotted — a date years behind its counterpart in the dispatching repository is the tell.

A rolled-back INSERT still consumes its AUTO_INCREMENT value. The value is never reused. Every failed request that got as far as the insert therefore leaves a permanent, dated gap in the table’s primary-key sequence — a record of the attempt that survives the rollback.

When a request fails with no server-side log, that sequence stands in for the log.

Timing. Bracket each gap by the registration timestamps of the ids either side of it. Clusters reveal an operator retrying rather than distinct users failing.

Where in the call path it failed. A consumed id proves execution reached the insert. If an earlier step in the same method allocates a different resource first, then a failure upstream of the insert consumes no id at all — so the presence or absence of a gap discriminates between candidate throw sites that the stack trace cannot distinguish.

Whether orphans were left behind. A helper that joins the caller’s transaction rolls back cleanly and leaves only the gap. One that starts its own transaction, or a path that returns 200 and therefore commits, leaves a real orphan row per attempt — a materially different clean-up job.