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.