Terrence Daniels

spring-grpc's BOM was silently pulling protobuf-java below what user-contract's generated code needs, on user-service's actual runtime classpath — not just tests — since the module's first phase. Undetected until a test finally constructed a generated message at runtime. Fixed with an explicit version pin.

The module's first test (contextLoads) failed outright — Spring Framework's own bundled ASM can't parse JDK 25 class files during component scanning at all, deeper than an earlier Gradle-plugin-only version of the same issue. Checking user-service showed it had the identical latent risk, never caught because no test there had ever booted a real ApplicationContext. Fixed by bumping both modules to Boot 3.5.16.

The custom root task merging every module's JUnit XML into one HTML file had two real bugs: a failing test silently blocked the report from generating at all, and — separately — the task had no declared inputs, so Gradle kept serving a stale report instead of regenerating it. Both fixed; the report is now a genuine CI artifact on every run.

The first real CI run failed outright (Permission denied, exit 126) — gradlew had been committed from Windows without its executable bit, so git stored mode 100644 instead of 100755. Fixed with git update-index --chmod=+x, confirmed on a second real run.

Porting JwtPerimeterGuardGatewayFilterFactoryTest and actually running it — never assumed — showed two of its three cases asserting an HTTP response status the filter itself never sets; that translation only happens through GlobalExceptionHandler, a layer absent from an isolated filter unit test. Failed immediately with onError instead of the expected onComplete. Rewritten to assert the filter's real, provable contract instead.

GitHub CodeQL flagged OrderController logging a whole request record whose itemCode field is free-form client input with no character restriction — \r/\n bytes could forge fake log lines. Fixed by logging fields individually and stripping control characters from the one field that actually needed it.

No registration RPC exists in this repo, and every test mocked PasswordEncoder with a literal placeholder hash — so the real bcrypt encode() path had never run once, in production code or tests. Added a real encode/matches round-trip test.

Login returned three distinguishable gRPC statuses depending on unknown-email vs. wrong-password vs. inactive-account, letting a caller enumerate registered emails — and their active status — without ever guessing a password. Collapsed to one generic UNAUTHENTICATED response after weighing the UX tradeoff.

Even after closing the status-code leak above, unknown-email and inactive-account logins skipped the deliberately-slow BCrypt comparison entirely, responding measurably faster than a real login attempt. Restructured so every path pays the identical real BCrypt cost, verified by reverting the fix and confirming new tests fail against the old code first.

The sibling code in api-gateway-service already caches its JWTVerifier once at construction for performance; this file rebuilt one on every single verifyToken() call. Matched the established pattern — zero behavior change, existing tests passed unchanged as proof.

Unlike every other module's repositories, user-service had no @DataJpaTest coverage at all — findByEmail and the email column's unique constraint had never been verified against a real database. Added tests including a real proof the unique constraint is genuinely enforced.

Neither Kafka listener caught anything — an event referencing an unrecognized order ID or a malformed payload fell through to Spring Boot's autoconfigured default with nothing in the code announcing that. Verifying that default for real turned up a second bug: an earlier write-up had already mischaracterized it as retrying indefinitely, when the actual behavior is 10 rapid retries then a silent drop. Fixed with an explicit, bounded error handler — and the inaccurate claim corrected in the same PR.

The same client-controlled itemCode field CodeQL had already flagged once (item 06) turned out to have a second, cross-service path to an unsanitized log line: order-service → payment-service → restaurant-service's raw string-concatenated rejection reason → back into order-service's own cancelOrder. Traced end-to-end before being fixed with the same sanitizing pattern already established for the first instance.

Two inbound Kafka events carried customerId (and one carried ticketId) all the way into confirmOrder/cancelOrder without either method ever checking them — a real asymmetry against this repo's own established pattern of validating every field on an inbound event. Fixed by cross-checking customerId against the order already on record, catching a corrupted or mismatched message on the shared topic instead of trusting it blindly.

The transactional outbox's Kafka send blocked on an unbounded Future.get(), implicitly relying on Kafka's own undocumented 120-second client default while holding a database row lock open the whole time — a degraded broker could have held that lock for up to 20 minutes across a full batch. Fixed with an explicit, bounded timeout.

PaymentStatus.FAILED was declared but dead code — processPaymentSaga unconditionally approved every payment, so the saga's own decline/compensation path was unreachable. Added a real, deterministic decline rule (a configurable authorization limit) and a guard so a declined payment can never be incorrectly refunded, cascading a matching fix into restaurant-service ahead of that module's own audit turn.

handleOrderCompensation refunded a payment using only the order ID off the inbound event, never cross-checking the customer ID against the payment it was refunding — unlike order-service's identical compensation path, which already guards against exactly this class of corrupted/mismatched Kafka message. Added the same cross-check.

No path anywhere in the repo could create an InventoryItem row outside of tests — no seed script, no replenishment endpoint. Every real order would hit ITEM_NOT_FOUND unconditionally, the module's core function unreachable in any actual deployment. Added seed data covering all three outcomes, and caught a genuine H2/Postgres SQL portability bug while verifying it.

RestaurantService uses an existsByOrderId check-then-act idempotency guard against duplicate PaymentProcessedEvent delivery — a real occurrence under Kafka's default at-least-once semantics, not theoretical — but the order_id column itself had no unique constraint backstopping it, unlike payment-service's identical guard. Fixed by matching that existing precedent, plus a test proving a duplicate insert is genuinely rejected.

Running ./gradlew test aggregateTestReport in one invocation could intermittently fail Gradle's own safety validation: the report task read each module's test-results directory without any declared ordering relationship to the test task that writes it, so a same-run schedule could read a directory before it was ready. Reproduced reliably, then fixed with an explicit ordering hint that doesn't force tests to run or block the report on a failure — preserving the task's deliberate "merge whatever results exist, pass or fail" design.

A log-injection alert flagged since PR #55 stayed open through two follow-up fix attempts, each leaving a code comment admitting it was "still flagged" without ever closing the loop. Investigated properly this time: two more fix attempts, each verified against a real CodeQL run, each cleared the prior alert only to reveal a new one at the next line — confirming the value was already being sanitized correctly the whole time. Researched CodeQL's own sanitizer source to confirm it, then formally dismissed the alert with a documented reason instead of leaving another silent "still flagged" comment behind. The branch split and shared sanitizer helper written along the way are kept as real clarity improvements.

The third occurrence of the same gap: kafkaTemplate.send(message).get() blocked unbounded on Kafka's own undocumented 120s default while holding a database row lock open the whole time, identical to the bugs already fixed in order-service and payment-service. Fixed with an explicit, bounded timeout. Verified via deliberate revert — reverting makes the new test fail to compile, not just fail, a genuine compile-time proof.

No DefaultErrorHandler anywhere in the module — an uncaught exception from a malformed payload fell through to Spring Boot's autoconfigured default (10 retries at 0ms backoff, then silent log-and-skip). The same gap already fixed in order-service and payment-service's own Kafka consumers. Fixed with a bounded backoff and a non-retryable exception list, verified via deliberate revert.

verifyAndDeductStock read an item's stock with a plain findById, then wrote the deduction back with no locking — two concurrent orders for the same item could both read the same stock count, both pass the check, and both get allocated. Reachable once the service scales past one instance, since the Kafka message key is orderId, not itemCode. Proved with a real @SpringBootTest firing two genuinely concurrent calls — [ALLOCATED, ALLOCATED] without the fix, [ALLOCATED, INSUFFICIENT_STOCK] with it. Fixed with a pessimistic-write row lock.

The login endpoint's blocking gRPC call was wrapped in Mono.fromCallable(...) with no scheduler override, on a comment's mistaken claim that spring.threads.virtual.enabled kept it off Reactor Netty's event loop — it doesn't; that setting only retargets servlet-style executors. Verified empirically with a real running server: the call executed on webflux-http-nio-2, a genuine event-loop thread, meaning every login could block one of a handful of threads shared by the whole gateway. Fixed with subscribeOn(Schedulers.boundedElastic()).

The JWT filter's catch-all handler logged a failed token's exception message raw. Extracting auth0's java-jwt source jar confirmed JWTDecodeException embeds the raw, attacker-controlled, base64url-decoded token segment verbatim into its own message — so a Bearer token whose payload decoded to non-JSON text containing literal CR/LF could forge fake log lines, unauthenticated, before signature verification ever ran. Fixed by sanitizing the message before logging, the same pattern already used for OrderService's identical finding.

The gRPC login client logged the submitted email raw, twice, on every attempt — a @RequestBody record field with no character restrictions, so a JSON body's CR/LF escapes could forge fake log lines on an endpoint that needs no authentication to reach at all. Fixed with the same sanitizing pattern used everywhere else this class of bug turned up, plus a real test class added where none existed before — the client's own logic had zero coverage anywhere in the suite.

Found while bringing the whole stack up in real Docker containers for the first time: the very first order request — a cold cross-container HTTP call, DNS resolution and connection-pool warmup included — took 1.29 seconds and got a false-positive circuit-open fallback under Resilience4j's undocumented library default. Fixed by configuring an explicit 5-second TimeLimiter, then re-verified from a fresh stack restart that the very first cold call succeeds.

Real end-to-end verification (not caught by any unit test — every test subscribes before the emission it's checking) showed a client connecting after an order had already reached SUCCESS still saw it flicker back through PENDING first. Root cause: Sinks.many().multicast().onBackpressureBuffer() queues any emission made while nobody's subscribed and replays the whole backlog to the next arrival, regardless of relevance. Fixed by switching to directBestEffort(), which only delivers to a subscriber connected at the exact moment of emission.

Spring Cloud Gateway Server WebFlux's own MethodRoutePredicateFactory matches a request's literal HTTP method with zero preflight-awareness — a route restricted to POST or GET never matches a real browser's OPTIONS preflight at all. Confirmed via bytecode inspection of AbstractHandlerMapping.getHandler(): its CORS-processing step only runs once a route has already matched, so an unmatched preflight falls through unrouted regardless of how the CORS config itself is written. Fixed by adding OPTIONS to every guarded route's method predicate — safe, since a matched preflight is still short-circuited before any route filter runs.

A real preflight to /auth/login kept getting rejected with 403 even though the gateway's CORS config looked correct on paper — the identical origin worked fine on a gateway-routed path. Diagnosed empirically with a temporary diagnostic WebFilter before writing any fix: Spring's own @RestController dispatch (AuthenticationController) claims /auth/login before the gateway's own routing ever sees it, and the CORS config was only ever wired into the latter — so the path actually being served had no CORS configuration behind it at all, invisible from reading the YAML alone. Fixed with a HandlerMapping-agnostic CorsWebFilter that applies uniformly regardless of which mapping serves a request. A real Dockerfile inefficiency found in the same debugging pass — no BuildKit Gradle cache mount, costing 10+ minutes per rebuild — was fixed in the same change.