Rider app: duplicate rows in Past earning activities

Investigated — this is a rider-app UI bug, not a data/idempotency problem

Traced the full path (rider app → rider API → production DB). The two identical "Wednesday 27 May — ৳239.31" rows are two genuinely separate deliveries, not a duplicated record. So there is nothing to make idempotent here.

DB proof (dinebd-rider.deliveries, rider 654cc3b2…, 27 May 2026)

Five distinct delivery records at fare 239.31, all different _id and different deliveredAt — two of them DELIVERED:

| _id | deliveredAt | status | fare | |---|---|---|---| | 6a16cd20… | 17:11:16 | DELIVERED | 239.31 | | 6a16d48f… | 17:28:49 | DELIVERED | 239.31 |

Those two DELIVERED rows are exactly what the client saw. No double-write, no double-submit — the API returned two real, distinct jobs.

What the rider app does wrong (the actual mistake)

File: lib/src/feature/income_and_delivery_history/income_history/today_income_history.screen.dart

The screen is labelled "Past earning activities" (a daily-earnings framing), but it fetches and renders one row per individual delivery, showing only day-name + date + fare — with no time, no order ID, nothing to distinguish two jobs on the same day.

1. Data source is per-delivery, not per-day. today_income_history.screen.dart:40 fires WeeklyDeliveryHistoryFetchingEvent, which in delivery_history_bloc.dart:_onWeeklyDeliveryHistoryFetching calls:

   getDeliveryHistory(page: 1, limit: 7, status: DELIVERED)
   

   → the 7 most recent individual DELIVERED deliveries, not a per-day aggregate.

2. Rendered one ListTile per delivery (_pastEarningHistoryWidget, ~line 256–283):

   ListView.builder(
     itemCount: data?.nodes?.length,          // one row PER DELIVERY
     itemBuilder: (context, index) => ListTile(
       title:    dayName(data.nodes[index].deliveredAt),   // e.g. "Wednesday"
       subtitle: dateFormat(data.nodes[index].deliveredAt), // e.g. "27 May, 2026"
       trailing: data.nodes[index].riderFare,               // e.g. ৳239.31
     ),
   )
   

   Two deliveries on 27 May with the same fare therefore produce two rows that are byte-for-byte identical on screen → looks like a duplicate, but it's two real jobs.

3. Inconsistent with the income chart on the same feature. The chart (dinebd__api.rider delivery-chart.resolver.ts) already groups by day and $sums riderFare server-side. The "Past earning activities" list does not group at all — so chart and list disagree by design.

Recommended fix (UI only — no API/data change)

Given the "Past earning activities" / "daily income" framing the client expects, group by day in the list:

• Group data.nodes by deliveredAt calendar day and sum riderFare, rendering one row per day (e.g. "Wednesday 27 May — ৳478.62 · 2 deliveries"). This matches the chart and the client's mental model.

Alternative (if per-delivery rows are actually intended): keep one row per delivery but add a distinguishing field (pickup time, restaurant name, or order ID) so same-day/same-fare jobs are visibly distinct.

Classification: rider-app (Flutter) UI bug. Board Project = rider-app is correct. Priority stays Low. Not related to idempotency, order double-submit, or the rider API.