[accounting][payment] add order lookup and refund flow - #3335
Conversation
Lays the groundwork for a future order-management UX (e.g. a chatbot
that looks up orders and requests refunds).
- Read-only OrderService on accounting (GetOrdersByEmail, GetOrder).
Accounting becomes an ASP.NET Core gRPC host alongside its existing
kafka consumer. The accounting."order" schema and the OrderResult
proto gain email, user_id, transaction_id, total_cost, order_status,
timestamps, and refund_transaction_id.
- PaymentService.Refund rpc + handler, gated by a new
paymentServiceRefundFailure flagd flag. On success, payment publishes
a RefundResult to a new "refunds" kafka topic; accounting's consumer
subscribes to it and marks the order refunded (idempotent on replay).
- Frontend gateways + API routes for orders
(GET /api/orders[/:id], POST /api/orders/:id/refund). The refund
route fetches the order from accounting to validate ownership/status,
then calls payment directly; status flips asynchronously via the
kafka event.
- order-expiry sidecar in docker-compose reuses ${POSTGRES_IMAGE} to
delete orders older than 48h on a loop. The Helm equivalent is a
CronJob with the same psql one-liner — no new image to publish.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
One or more co-authors of this pull request were not found. You must specify co-authors in commit message trailer via: Supported
Alternatively, if the co-author should not be included, remove the Please update your commit message(s) by doing |
|
Hey @martinjt 18k LOC is not easily reviewable by humans. |
|
Huh, sorry, that was supposed to be a draft while I paired it down. |
|
TBF it is a draft 😅 |
|
Haha, well, my plan was to judge the acceptability of the premise then workout how to get it in. Would love your thoughts on it. |
|
I think adding a refund workflow makes sense. Will this eventually add new services/components as well? |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Changes
Lays the groundwork for a future order-management UX (e.g. a chatbot that
looks up orders and requests refunds). The demo currently has no read
path for orders and no refund flow.
OrderServiceonaccounting(GetOrdersByEmail,GetOrder);accountingbecomes an ASP.NET Core gRPC host alongsideits existing kafka consumer.
accounting."order"and theOrderResultproto gain
email,user_id,transaction_id,total_cost,order_status, timestamps, andrefund_transaction_id.PaymentService.Refundrpc + handler, gated by a newpaymentServiceRefundFailureflagd flag (mirrors the existingpaymentFailurepattern). On success, payment publishes aRefundResultto a newrefundsKafka topic;accounting's consumersubscribes to it and marks the order refunded (idempotent on replay).
(
GET /api/orders[/:id],POST /api/orders/:id/refund). The refundroute fetches the order from
accountingto validate ownership/status,then calls
paymentdirectly; the order's status flips asynchronouslyvia the kafka event.
order-expirysidecar indocker-compose.ymlreuses${POSTGRES_IMAGE}to delete orders older than 48h on a loop(configurable). The Helm equivalent is a CronJob with the same
one-liner — no new image to publish.
No order-management UX is included here; that lands in a follow-up.
Merge Requirements
For new features contributions, please make sure you have completed the following
essential items:
CHANGELOG.mdupdated to document new feature additions