Repository navigation
Native chat: rewind works at any chat length - #30394
Conversation
Rewind copied the kept part of the chat into its saved record and, for Codex, re-read and re-translated the whole provider history before and after the revert. Both were bounded (10,000 rows / 2 MB host, 1,024 entries / 2 MB Codex), so long chats were refused with "too long to go back in". The record now names the cut; the kept rows are derived from the journal, which keeps the old epoch until the rewind completes. Codex reads only the turns it undoes and trusts thread/revert; recovery proves an applied revert from the newest turn alone and never truncates otherwise.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 1 minute. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
… a record that exists
|
Long chats could refuse “Rewind to here” because Orca copied retained messages into a size-limited saved record and read Codex’s history through another size-limited path. This change removes those history-size refusals: rewind keeps Orca’s saved messages before the selected turn, finds the Codex turn a page at a time, and updates the conversation after Codex confirms the rewind. The full review loop completed two rounds on Fixed findings:
The three-model architecture panel unanimously ruled KEEP after reviewing the expanded implementation budget. It retained the common pattern of treating the app’s saved conversation as authoritative and keeping only the rewind boundary in the in-progress record. Two deliberate differences remain intended: completion still rewrites the kept messages into a new chat version so older paired clients recognize completion, and recovery checks Codex’s state rather than repeating a destructive rewind. Keeping subagent messages with their retained parent turn is also an intended behavior change. Deferred items, with their recorded labels:
Verification: 49 targeted tests passed, plus 23 explicit Node-runtime checks. The full PR workflow, run 39160047711, is successful on the exact reviewed head, including its aggregate gate, static analysis, tests, packaging and cross-version compatibility checks. The head and checks were verified again for this closing comment. The lane owner completed real Electron QA on the M4Air under ticket 398 after the loop’s earlier QA attempt was blocked by driver capacity. Grok drove a real signed-in Codex with a 3.3 MB saved history. All six reported flows passed: long-chat setup, rewind, continuation without the undone context, persistence after restart, short-chat rewind, and rewind after For Brennan’s review The branch screenshots below are the existing QA evidence from the PR body. Matching main screenshots were not captured.
Two places worth human attention:
|
1 participant
ELI5
In a long chat, "Rewind to here" said "This conversation is too long to go back in. Nothing was changed." Long chats are exactly where people want to go back. Rewind no longer refuses a chat because its saved history exceeds those limits.
What Changed
Before: to rewind, Orca copied every message it would keep into a saved record, and for Codex it also re-read Codex's entire history twice (before and after the revert) and translated it all back into chat rows. Each of those copies had a size cap: about 10,000 rows or 2 MB for the saved copy, and 1,024 turns-plus-items or 2 MB for the Codex read. A chat past any cap was refused. With large tool outputs, about 130 tool calls were enough.
After: rewind removes the selected turn and later turns without those history-size refusals.
Rejected messages, including messages stopped before delivery, are omitted after rewind just as before. Preserving earlier submission status during rewind is tracked separately and is outside this length-limit change.
Why
The common pattern for going back in a chat keeps the app's own message store authoritative. It marks or deletes only the undone part by reference, and stores only ids for a rewind in progress. This adopts that authority and the small in-progress record. The existing completion write still takes work proportional to the kept history, as described below.
Differences, each intended:
Alternative rejected: raise or remove the caps but keep the copy and the full re-read. The saved record would grow without bound, since it is rewritten whole on every step. A long Codex chat would also re-read and re-translate its whole history twice per rewind.
Linked Issue
Tracked in the native-chat audit (data limits D-K4, provider limits #7). No GitHub issue.
Visual Proof
Real Orca build of this branch on a Mac (M4Air), driven through the app with a real, signed-in Codex. The chat's Codex history was 3.3 MB before the rewind, past the old 2 MB limit. All six flows passed; "This conversation is too long to go back in" never appeared.
Not shown: the same chat on a build of main. The 3.3 MB is the size of Codex's saved history file; the automated tests are what pin the old refusal and its removal.
Testing
Review
Agent skill upstream boundary
Notes
retainedfield becomes optional and is no longer written. A rewind left half-done by an older build can recover from the chat history when the provider outcome can be established; an uncertain outcome remains unresolved.Author: @BrennanKB5
Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (CI will cover)