Order status updates + history (backend) — #41, #42#100
Merged
Conversation
…41, #42) #41 Get Order Status: status previously never advanced past placement. Add an Event Hub BackgroundService (OrderStatusConsumer) that reads bot events from the simulator's robot-output hub and advances order status: - RobotOrderAssignmentResponse: Accepted->InTransit, Queued->Assigned, Rejected->Failed - RobotStatusUpdated: OnDelivery->InTransit, DeliveryCompleted->Delivered - RobotDeliveryCompleted->Delivered Mapping is a pure, forward-only function (out-of-order/duplicate events can't regress status). Correlates by the order GUID we emit in RobotOrderAssignment; verified against the merged simulator source that it echoes that id back. Idle-with-warning when StatusConsumer config is absent so the API still runs. #41/#42 read endpoints (GetOrder, GetOrderHistory) already existed but were untested; add 22 unit tests covering the read paths, the pure status mapping, and persisted status transitions. IaC (Iac/order-service): dedicated 'order-service' consumer group on robot-output + StatusConsumer env vars, reusing the namespace-level eventhub-connection-string secret (has Listen on robot-output). terraform validate passes.
Orders were rejected by the simulator ('Item beverage is not stocked by this
bot') because OrderService emitted abstract item ids (food/beverage/package)
while the simulated bots stock water/soda/chips/sandwich (RobotSimulator
BotFleet). Map order options directly to the simulator catalog instead; default
unrecognized values to water (always stocked) so orders aren't rejected.
Verified live against the deployed simulator: it echoes our order GUID back in
RobotOrderAssignmentResponse, confirming the status-consumer correlation.
Note: this is Place Order (#40) contract logic, folded into this PR per request.
Frontend dropdown (customer-webapp, crawfordkid2) still lists the old types and
should be updated to water/soda/chips/sandwich as a follow-up.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
Implements the backend for #41 Get Order Status and #42 View Order History.
closes #41 and #42
The
GET /api/orders/{id}andGET /api/orders?customerId=endpoints alreadylanded on
main(via #81) but were untested, and the core of #41 — statusupdates when the Order Service receives bot update events — did not exist:
order status was set once at placement and never advanced.
Changes
OrderStatusConsumerBackgroundService reads botevents from the simulator's
robot-outputhub and advances order status:RobotOrderAssignmentResponse: Accepted→InTransit, Queued→Assigned, Rejected→FailedRobotStatusUpdated: OnDelivery→InTransit, DeliveryCompleted→DeliveredRobotDeliveryCompleted→DeliveredRobotOrderAssignment. Verifiedagainst the merged simulator source that it echoes that id back in
data.orderId/activeOrderId/previousOrderId.pure event→status mapping, and persisted status transitions.
Iac/order-service): dedicatedorder-serviceconsumer group onrobot-output+StatusConsumer__*env vars, reusing the existing namespace-leveleventhub-connection-stringsecret (confirmed it hasListenon the namespace — nonew secret or role assignment needed).
terraform validatepasses.Frontend — out of scope (note)
The "on site" part of the acceptance criteria (#41 query-by-id, #42 view-history) needs
UI in the
customer-webapp, which is crawfordkid2's area. It is intentionallynot in this PR to avoid stepping on that work. Meanwhile both endpoints are
exercisable via Swagger (enabled in all environments). The two pages
(Track Order, Order History) should be added by the frontend owner as a follow-up.
Already done outside this diff
deliverybot-order-service) was created asa DB user + added to
db_owneronOrderServiceDb/jacob-orderservice-sql2Refs #41, #42