Repository navigation
[Bug]: A fork made after Edit from here shows the rewound turns #30030
Description
What happens
After Edit from here rewinds a thread, the rewound runs stay in storage as rolled_back with their run ordinals. A fork reads its source's turns up to the forked run by ordinal only (visibleTurnItemsThroughRun in ProjectionStore.ts), so a fork made after the rewind shows the turns the source threw away. The agent in the fork never received them, because the portable handoff drops rolled-back runs, so the timeline and the agent disagree.
Steps to reproduce (main cefb544af3)
- Send two prompts in a thread (any provider with rewind).
- Use Edit from here on the second prompt, then send a third prompt.
- Fork from the third reply.
- The fork shows prompts one, two and three. The source shows one and three.
Expected
The fork shows prompts one and three. A fork made before the rewind should keep its rows, as it does now ("keeps fork visible items stable after a source run is rolled back").
I have a fix with a failing-first test, proven on web and Android. It needs no contract change, because rollback already stamps completedAt with the rewind time. I can open a PR if you want one.
Activity
[-]A fork made after Edit from here shows the rewound turns[/-][+][Bug]: A fork made after Edit from here shows the rewound turns[/+]Entrpi commentedon Nov 3, 2026
The fix is on our fork as one commit on top of
main(cefb544):20ec516(compare).It includes the failing test in
ProjectionStore.test.ts, which fails onmainfor this reason and covers the projection, the timeline index, the shell count and the windowed read. Happy to open it as a PR if you want it.Entrpi commentedon Nov 5, 2026
#29695 (open) fixes this too. It finds the same cause, inherited rows filtered only by
run.ordinal <= forkRun.ordinal, and covers the projection, the timeline index and the windowed SQL read. It isn't linked to this issue, so I'm noting it here so this can close when it lands.