⭐ Order Service

order-service is the saga's entry point and the sole owner of an order's overall lifecycle state (PENDING → SUCCESS/CANCELLED). Its topics, port, and schema are on the services-reference.html diagram; the full request path is on saga-flow.html.

OrderController used to trust CreateOrderRequest.customerId directly — a tracked gap from before api-gateway-service existed to inject a verified caller identity. Now that it does, the code-review audit closed it: OrderController reads the gateway's X-Perimeter-User-Id header and rejects with 403 on any mismatch or missing header. Fixing it tripped a fresh CodeQL log-injection alert on the rejection's own log line — twice, since the first sanitizer (a ternary) wasn't one CodeQL's analysis recognized as a real barrier. See docs/code-review.md for the full sequence.

A GitHub CodeQL scan separately flagged a real Medium-severity log-injection finding here after deployment (CWE-117): a log line used to interpolate an entire request record, including an unvalidated, unbounded itemCode field straight off the public request body. Fixed by logging fields individually, with itemCode sanitized. The only call site of its kind found across all five modules — at the time. The code-review audit later traced a second, cross-service log-injection path through this same itemCode field, reaching OrderService.cancelOrder via payment-service/restaurant-service — fixed there with the same sanitizing pattern once that file's own review came up, alongside a real customerId/ticketId validation gap in the same two methods. A separate Kafka poison-pill risk (an uncaught OrderNotFoundException silently dropped by Spring Kafka's default error handling) was fixed in OrderConsumerConfig.java's own review, which also corrected an earlier write-up's inaccurate claim about that default's actual retry behavior. order-service's code-review audit is complete — 15/15 files, 5 issues fixed, 0 findings left open.