kingRayhan
dinebd__api.business#153
Reported by Yemon (DineBD CEO) via WhatsApp, 10 Jul 2026. Evidence: issues/yemon-inbox/2026-07-10-order-complete-refund-mess/
It was manually assigned the rider and order was completed. But now showing order time out and refund given. The whole things has gone mess
Can you check rider invoice and rider due amount and see if there are updating accordingly as it should
Investigate and fix order FD-20249178-353 (Food Delivery, BDT 38.00, ordered 10 Jul 2026 ~4:21 PM).
Observed in admin (business dashboard):
Preliminary analysis (agent, Jul 2026):
Timing matches no-rider timeout (~30 min) — order at 4:21 PM, refund log at 4:55 PM. Rider API NoRiderTimeoutService fires initiateFoodDeliveryRefundForTimeout when delivery stays NO_RIDER_FOUND for ~30 minutes.
initiateFoodDeliveryRefundForTimeout does not guard completed orders (food-delivery.grpc-controller.ts) — it always calls initRefund and forces business order status to TIMEOUT, even if the rider later completed the delivery.
syncStatus gRPC bypasses onUpdate hook (food-delivery.grpc-controller.ts) — rider → business status sync uses direct updateOne({ status }) only. Side effects skipped:
deliveredAt never set → admin shows DELIVERED + "Not Delivered"sendOrderStatusChangedEvent never fired → Inngest vendor timeout may not cancelManual assign does call cancelNoRiderFoundTimeout (rider-action.service.ts) — so if assign happened before the Redis timer expired, refund should not fire via no-rider path. Need prod logs/timeline for FD-20249178-353 to confirm whether assign completed after timeout or timer cancel failed.
Likely failure modes (verify on prod):
deliveredAt; refund row still exists from earlier timeout eventsyncStatus through syncStatusFromRider() so onUpdate runs (timestamps, Inngest cancel, socket events)initiateFoodDeliveryRefundForTimeout — only allow when status is FINDING_RIDER or NO_RIDER_FOUNDdelivery.assignedRider is setinitiateFoodDeliveryRefundForTimeout must check rider delivery + business order status)syncStatus sets timestamp fields (deliveredAt, etc.) and cancels scheduled timeouts (use service layer / onUpdate, not raw updateOne)None — code fix merged; prod deploy + order audit remaining
refund-log-fd-20249178-353.png — Refund log: order FD-20249178-353, BDT 38.00, refund 202606-0935, status Waiting for customer action, created 10 Jul 2026 4:55:55 PMorder-list-delivered-not-delivered.png — Order list: FD-20249178-353 marked DELIVERED (green) but Delivered at column shows Not Deliveredapi/dinebd__api.business/src/api/food-delivery-order/food-delivery.grpc-controller.ts — syncStatus, initiateFoodDeliveryRefundForTimeoutapi/dinebd__api.rider/src/api/delivery/services/no-rider-timeout.service.tsapi/dinebd__api.rider/src/api/delivery/rider-action/rider-action.service.ts — manualAssignRiderToDeliverykingRayhan
kingRayhan
Two PRs merged to address the root causes identified in this issue:
syncStatus → syncStatusFromRider() — rider status sync now goes through the service layer so onUpdate runs:
deliveredAt (and other status timestamps)sendOrderStatusChangedEvent (cancels Inngest vendor timeout)deliveredAt is missing, it gets backfilledinitiateFoodDeliveryRefundForTimeout only proceeds when business order status is FINDING_RIDER or NO_RIDER_FOUND; skips completed/in-progress ordersdelivery.assignedRider is setsyncStatus sets timestamp fields and cancels scheduled timeoutsdeliveredAt populated