fix(usage,responses): 兩處讀取沒有上限，並把 PR/issue 查法改成 --state all - #2
Conversation
引用上游 dev 上的兩支修正，兩者的缺陷都在本 fork 實查確認： - lidge-jun#2395：readUsageEntriesIncrementally() 只擋檔案縮小，沒擋一次 append 太多。 兩次輪詢之間灌進來多少就整批讀多少並逐行解析，繞過 maxReadBytes 這個唯一的 記憶體上限——而且是在帳本長最快的時候繞過。補 4 行守衛交還給 full-tail reader。 - lidge-jun#2398 前半：bounded-body 的兩個進入點在 signal 已 aborted 時先 throw，此時 還沒掛 reader，原始 body 沒被結束，fetch 背後的 stream 會留著一個被拒絕的 read。補 cancelBodyWithoutWaiting()。不引用後半的 readDisplaySafeErrorText 重構（依賴 dev 的新介面），觸發條件記在 docs/fork/UPSTREAM.md。 兩條測試取自上游同 PR 並改寫；把 src 改動 stash 掉重跑確認都會紅。 查法缺口：先前查 PR/issue 用 --state open，看不到未合併就關閉的項目——那正是 上游拒收但可能對本 fork 有價值的一類。改成 --state all，水位 PR lidge-jun#2433、 issue lidge-jun#2434。同時把 fork-hygiene 裡寫死 reviewed_date 的斷言改成日期格式， 否則每做完一次審查那條測試就變紅。 typecheck 乾淨、privacy:scan 通過、fork-hygiene 18 pass、bounded-body 27 pass、 api-usage 25 pass。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dc9e125353
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 1. 查 PR 與 issue **一律用 `--state all`**。未合併就關閉的 PR 永遠不會經由 commit 路徑抵達， | ||
| 而那正是「上游拒收、但可能對本 fork 有價值」的一類。 |
There was a problem hiding this comment.
The new rule is not implemented by the scheduled checker: tools/check-upstream-updates.ts:150 still invokes gh issue list --state open, although gh issue list --help confirms that all is supported and open excludes closed issues. Consequently, a tracked platform issue that opens and closes between weekly runs is omitted, and once a higher-numbered issue advances reviewed_issue_through, it will never be triaged. Update the collector and its focused tests to use --state all rather than changing only the documented/manual review process.
Useful? React with 👍 / 👎.
上游引用
上游的
dev目前領先main69 個 commit，而本 fork 的取用點是main。判準（見 docs/fork/DECISIONS.md）是「dev上有沒有本 fork 現在就會痛的修正」。本輪兩支都符合，且缺陷都在本 fork 的程式碼裡實查確認：src/usage/log.ts的readUsageEntriesIncrementally()只擋「檔案縮小」，沒擋「一次 append 太多」。兩次輪詢之間灌進來的位元組不論多大都走增量路徑整批讀進來並逐行解析——繞過maxReadBytes這個唯一的記憶體上限，而且是在帳本長最快的時候繞過。src/lib/bounded-body.ts的兩個進入點在 signal 已 aborted 時先 throw，此時還沒有 reader 掛上去，原始 body 沒被結束，fetch 背後的 stream 會留著一個被拒絕的 read。不引用 lidge-jun#2398 後半（
readDisplaySafeErrorText，core.ts +65 行）：依賴dev上的新介面，硬移植等於自行改寫。觸發條件記在 docs/fork/UPSTREAM.md。測試有牙齒
兩條測試取自上游同一個 PR 並改寫成本 fork 的檔案結構。把 src 改動
git stash掉重跑：bounded-body1 fail、api-usage1 fail；改動放回全綠。順帶修掉的兩個查法/測試缺口
--state open——看不到未合併就關閉的項目，而那正是「上游拒收但可能對本 fork 有價值」的一類。改成--state all，水位推進到 PR fix(combos): fail over zero-output stream failures lidge-jun/opencodex#2433、issue [Feature]: keep Responses fetch helpers on a transport-only import boundary lidge-jun/opencodex#2434。tests/fork-hygiene.test.ts把reviewed_date寫死成2026-08-22。那表示每做完一次上游審查，這條測試就會變紅——把完成的工作變成紅燈。改成斷言 ISO 日期格式；「這個日期有沒有記進 DECISIONS.md」由下一條測試守。驗證
bun run typecheck乾淨、bun run privacy:scan通過、fork-hygiene18 pass、bounded-body27 pass、api-usage25 pass。