Back to board

Rider: Lubna not receiving auto job alert for Yemon Kitchen orders

dinebd__api.rider#55

Description

Reported by Yemon (DineBD CEO) via WhatsApp, 11 Jul 2026. Evidence: issues/yemon-inbox/2026-07-11-lubna-yemon-kitchen-no-alert/

Client report

When Yemon order come from Yemon Kitchen, rider can't get auto onboarding alert.

Rider: Khadiza Akter Lubnak.a.lubna24@gmail.com (Rider ID 000051)

What to observe

Case under review — watch whether Lubna receives job radar / ringtone / push when a new Yemon Kitchen food delivery is dispatched.

Prod investigation summary (11 Jul 2026)

| Check | Result | |-------|--------| | Distance to Yemon Kitchen pickup | 352 m — not a location issue | | Dispatch rank | #1 nearest rider within 5 km | | Account | ACTIVE, APPROVED | | isOnline at check time | false (app not pinging location) | | Backend invite (FD-20249178-357) | YesNew Delivery Order notification created | | Gap invite → manual assign | ~39 s (suggests no in-app response) |

Working hypothesis: backend dispatch + DB notifications OK; alert not reaching phone (app closed, socket/FCM, or notification permissions).

Observation checklist (next Yemon Kitchen orders)

  • [ ] Lubna has rider app open and logged in before test order
  • [ ] Location + notification permissions enabled
  • [ ] Place Yemon Kitchen order → note if job radar / sound fires on her device within ~5 s
  • [ ] Confirm rider admin shows FINDING_RIDER → invite (not straight to manual assign)
  • [ ] Check prod: users.isOnline=true for Lubna during test
  • [ ] Check prod: notification row New Delivery Order created for her rider id
  • [ ] Record outcome: alert received / not received / manual assign needed

Follow-up fixes if observation confirms hypothesis

  • [ ] Rider app: verify FCM topic rider.{userId} subscription on login
  • [ ] Rider app: verify socket joins emit:rider-onboarding:join-room while on duty
  • [ ] Rider API: consider dispatching only to isOnline: true riders (optional hardening)

Acceptance criteria

  • [ ] Reproduce with Lubna on duty — auto alert received on device for Yemon Kitchen order, OR root cause documented with logs
  • [ ] No manual assign required for normal flow when rider is online and near kitchen
  • [ ] Case notes added to this issue after 1–2 test orders

Blocked by

Waiting on client/rider to test with app open during next Yemon Kitchen order

Related

  • dinebd__api.rider #53 — manual assign + NO_RIDER_FOUND status (separate bug, PR #54)
  • dinebd__api.business #153 — timeout/refund after manual assign (merged)

Related code

  • api/dinebd__api.rider/src/api/delivery/rider-onboarding/rider-on-boarding-processes.service.ts
  • api/dinebd__api.rider/src/api/user/user.service.ts — online pulse (10s TTL)
  • mobile-apps/dinebd__mobileapp.rider — socket + FCM job alerts
Comments (3)
Synced 10 Sept 2026, 05:33

kingRayhan

Investigation update + fix in progress

Symptom (Lubna, FD-20249178-358 @ ~5:39 PM)

  • Got 2–3 push notifications (New Delivery Order)
  • Rider app Job Radar showed emptyTotal delivery pending (0)
  • Screenshot matches: notifications received, no job in list

Root cause — Rider API, not rider app UI

Job Radar uses GraphQL myJobs. The query only returned:

  1. Deliveries assigned to the rider, or
  2. Invites where status = NO_RIDER_FOUND

But auto-dispatch push alerts fire during FINDING_RIDER (normal onboarding). That status was excluded from myJobs, so the API returned [] while notifications were sent.

Prod evidence for FD-20249178-358:

  • Lubna in requestReceivedByRiders
  • Notifications at 11:39 & 11:43 UTC ✓
  • myJobs count = 0 (status was FINDING_RIDER → later TIMEOUT)
  • Order ended TIMEOUT, never assigned

Fix

PR: https://github.com/graphland-dev/dinebd__api.rider/pull/56

Add a third myJobs branch:

status = FINDING_RIDER AND lastOnBoardingRiderId = current rider

This shows the active invite in Job Radar for the ~40s onboarding window — matching when push is sent.

After deploy — re-test

  • [ ] Lubna app open, location + notifications on
  • [ ] Yemon Kitchen test order → Job Radar should show job when push arrives
  • [ ] Accept from Job Radar without manual assign

kingRayhan

Duplicate delivery fix (FD-20249178-359)

Root cause: business onUpdate can call sendDeliveryOrderToRiderService again while status stays ACCEPTED_BY_VENDOR, creating a second rider delivery ~95s later → duplicate notifications + Job Radar cards.

PRs:

  • Rider (idempotent create): https://github.com/graphland-dev/dinebd__api.rider/pull/57
  • Business (atomic dispatch claim): https://github.com/graphland-dev/dinebd__api.business/pull/155

After merge: rider auto-deploys from main; business needs merge to prod for production.

kingRayhan

Cross-link: same symptom tracked on rider app as graphland-dev/dinebd__mobileapp.rider#187 (Job push + ringtone but Job Radar empty).

Backend fix: PR #56 merged & deployed — myJobs now returns active FINDING_RIDER invites.

Closing this as the API-side root cause; #187 remains open for app-side ringtone/refresh verification.

Details
In Review🔥 HighRider Appopen
Repository
graphland-dev/dinebd__api.rider
Issue
#55
Author
kingRayhan
Created
11 Jul 2026, 11:32
Updated
11 Jul 2026, 11:32
bug