fix(app): 「我的行程」只看得到最近 20 趟——舊行程的協尋與補評分入口整個消失（第二十四輪）

[thothawei]

先講開工撞到的事

TODO 寫的下一輪首選（前景服務被系統收走）已經被 #94 認領，另一支 #95 在做預約司機＋常用地點。所以本輪換族，盤點「清單的資料量上限」這個從沒碰過的角。

根因

fetchRideHistory() 固定要 20 筆、畫面沒有任何「載入更多」，而「我的行程」是事後聯絡司機／申報遺失物／補評分的唯一入口——第 21 趟以前的行程在乘客端永遠打不開。

盤點下來這一族只有這一個真洞：對話與協尋清單都不帶 limit（後端 MaxListRows=5000），收入頁是依月聚合。後端 GET /api/customer/rides 的 limit 照單全收，所以不用動 dispatch。

修法

• 捲到底自動再要一頁。沒有 cursor 就別假裝有：後端只有 limit、沒有 offset，所以「載入更多」是把 limit 加大重讀，不是接續抓下一段。代價是剛好整除時多要一次；好處是順帶更新已顯示那幾筆的評分／協尋狀態。
• 失敗訊息分兩條：historyMoreError 與 historyError 分開——已經載進來的行程還在畫面上，錯誤只該長在清單尾巴。失敗時視窗不推進，重試要的是同一段。
• 下拉刷新保持已展開的筆數（捲到第 60 筆的人不該被縮回 20 筆），登出才收回一頁。
• 尾巴不是按鈕是自動載入——舊行程是「想起有東西掉在車上」時才會翻的，多一次點擊就多一個放棄點；只有失敗時才退化成重試按鈕。

驗收

• flutter analyze 無 issue、flutter test 386 passed（377 ＋新 9）。
• 反向驗證兩半各一次：拿掉補讀 → 6 案 FAIL；拿掉畫面尾巴那一格 → 2 案 FAIL。
• 模擬器實跑（m6_pixel ＋本機 dispatch，customer flavor，以 API 造 25 筆行程 feat(app): 司機端聯絡電話填寫入口（O7 補洞）＋TODO 過期勾選回填 #41–fix(driver): 沒搶到的單不再給司機一張假的行程卡 #65）：

情境	後端實際收到的查詢	畫面
修好的版本：開畫面、不捲動	只有 LIMIT 20	最新 #65 起 20 筆
修好的版本：捲到底	LIMIT 20 → LIMIT 40（rows 20 → 25）	最舊 #41／pickup point 1 進得來
修改前的版本：同樣捲到底 14 次	只有一次 LIMIT 20	停在 #46／pickup point 6，第 21～25 筆沒有任何入口

證據取自後端 GORM 的 SQL log，不是只看畫面。dev DB 的 25 筆全部是 status=9 終態。

過程中踩到的兩條（已寫進 TODO）

1. 本機有兩個 redis 在搶 6379：主機的 redis-server 綁 127.0.0.1、docker 綁 *，REDIS_ADDR=127.0.0.1:6379 會連到主機那個；在容器裡 redis-cli KEYS 查不到鍵，會誤以為限流沒生效。
2. 造測試資料會撞叫車限流（5 次／分鐘，key 帶 line_user_id）：要配速，而且每筆建完得立刻取消，否則 FindActiveByCustomer 擋掉下一筆。

🤖 Generated with Claude Code

[thothawei]

追加一支 commit：把這輪踩到的兩個環境坑修掉，不只是記下來

• redis 撞埠 → dispatch PR #72：容器改發布 6380（與 postgis 讓開 5432 同一招）。本 PR 這邊把 TODO 的主機跑法更正為 REDIS_ADDR=127.0.0.1:6380。當初「6379 會連到本機那台」只是推論，事後對兩台各寫一個 whoami 鍵、用 raw socket 讀，才驗死。
• 造測試資料 → 新增 tool/seed_customer_rides.sh：配速避開 5 次/分的叫車限流、每筆建完立刻取消（否則 FindActiveByCustomer 擋下一筆）、建單失敗直接 exit 1 印回應（第一版 25 次全跑空還印得像成功）。已用 seed_customer_rides.sh 3 實跑驗過。

改完的閉環證據：用 6380 跑一輪建單後，ratelimit:* 出現在容器那台，主機那台是空的。

[thothawei]

追加兩支 commit：解掉與 main 的衝突，並回頭 debug 這支 PR 自己（抓到 1 個永久卡死）

這支開出來之後 #94（第二十三輪）與 #95（預約司機＋常用地點）先合併了，本 PR 變成 CONFLICTING。解完衝突之後沒有直接收工——把這支的新程式碼當成沒驗過的東西重查一遍，結果它有一個會永久卡死的狀態。

一、解衝突（三處，都是兩邊並存不是二選一）

衝突點	解法
customer_controller.dart 的 _clearSession()	分頁視窗（_historyWindow／_historyMoreError／_historyHasMore）與 #95 的常用地點／預約清除都要留——兩者都是「換人登入不能留上一位的資料」
docs/TODO.md 目錄	補回第二十四輪那行（原本兩邊各刪掉對方的）
docs/TODO.md 現況的測試數字	先留 main 的，收尾重數後再更正（寫作規則 4）

驗收：flutter analyze 無 issue、flutter test 423 passed（main 414 ＋ 本 PR 9）。

二、🐛 回頭 debug 抓到的真 bug：分頁的尾巴會卡死在轉圈

根因一句話：_HistoryFooter 只在 initState 觸發一次補讀，而 loadMoreRideHistory() 有「已經有請求在飛就 return」的重入防護——尾巴被建出來的那一刻若剛好有下拉刷新在飛，這唯一的一次觸發就被吞掉，之後沒有任何人再試一次。

症狀就是這支 PR 想修的那個病，在這條路徑上原封不動：尾巴永遠停在轉圈，第 21 筆之後的行程再也進不來，舊行程的協尋與補評分入口照樣打不開。

原本的 9 個測試為什麼抓不到：它們測的都是「補讀本身對不對」（視窗推進、錯誤分兩條、登出收回），沒有一個案子讓兩個請求在時間上重疊。這與預約那輪的教訓是同一條——沒有真的重疊的併發測試，測到的只是循序重跑。

修法兩個半邊，缺一不可：

1. 尾巴加 didUpdateWidget，每次 rebuild 都補問一次（rebuild 由 controller 的 notifyListeners 帶動，刷新一結束就會走到）。重入仍由 controller 擋，多問不會多打。
2. 但自動補讀失敗過就停手，交給既有的重試按鈕：didUpdateWidget 跟著每一次 notifyListeners 觸發，少了這道 guard 會在後端還沒恢復時變成連續打點。

順手補上跨年行程的年份：_dateLabel() 只印「1月5日 08:00」。跨年的行程是分頁上線後才翻得到的（在那之前只看得到最近 20 趟），而這一頁是事後申報遺失物、補評分的入口——找錯年份就是找錯那一趟。今年的不加年份，免得每張卡都變長。

三、驗收

• flutter analyze 無 issue、flutter test 425 passed（423 ＋新 2）、54 個測試檔。
• 抓 bug 的順序是先紅再修，而且紅的方式本身就是證據：pumpAndSettle timed out——因為尾巴那顆 CircularProgressIndicator 永遠不會停。這比任何斷言都直接。
• 反向驗證兩個半邊各一次：
  • 拿掉 didUpdateWidget → 新測試 FAIL（pumpAndSettle 逾時）。
  • 拿掉「失敗就停手」那道 guard → 既有的「載入更多失敗時清單還在，尾巴給重試」那案 FAIL，而且是 27 秒才逾時——正是自動重試打成迴圈的樣子。
• flutter build apk --debug --flavor customer -t lib/main_customer.dart 成功（app-customer-debug.apk）——analyze 綠不代表打得包出來。

四、這一輪掃過但沒有發現問題的（寫進 TODO，免得下一輪重掃）

掃的東西	結論
時區：全 repo 的 DateTime.parse／tryParse 與顯示點	✅ 送出 .toUtc()、顯示 .toLocal()，兩個方向都對
預約清單排序	✅ 後端 scheduled_at ASC, id ASC、App 的 _mergeScheduledRide 也 sort
常用地點／預約的載入路徑	✅ init() 與 _authenticate() 都載，登出也清
每個 *Error 欄位有沒有顯示點	✅ 6 個 getter 全部有對應畫面
.first／.last 有沒有空集合保護	✅ 7 處全部有 isNotEmpty 或三元退路
Timer／StreamSubscription／TextEditingController 的 dispose	✅ 有建就有 dispose
其他「一次性 initState 觸發＋重入防護」的組合	✅ 只有尾巴這一處

五、開工前的例行實查（本輪 = 第八次）

三個外部卡點依然都不在：android/app/google-services.json、ios/Runner/GoogleService-Info.plist 不存在、xcrun devicectl list devices → No devices found。

功能清單目前沒有「不需前置條件就能做」的項目（唯一未勾的 [ ] 車種供給為零等產品拍板；司機端行程歷史後端也還沒有端點——cmd/server/main.go 的 driver 路由只有 /driver/rides/active），所以本輪照 2026-07-28 立的規矩改做 debug。

🤖 Generated with Claude Code