[Bug]: A Pi session rewound natively by an extension leaves T3's timeline and turn refs on the abandoned branch #13507

Activity

1. juliusmarminge commented on Sep 24, 2026

   

   juliusmarminge

   on Sep 24, 2026

   Member

   More actions

   Triage: #13507 Pi native rewind leaves T3 on the abandoned branch

   Verdict: Valid. Still present on t3code/codex-turn-mapping at 393d7b346f. Pi lives on this V2 line (apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts); origin/main does not contain that file. No other issue matches.

   Severity: High on Pi threads that rewind outside T3. The timeline keeps prompts the model can no longer see, and a later T3 Revert forks at the wrong session-tree entry. Pi is Early Access. Threads that never call navigateTree, /tree, /fork, or /clone stay consistent.

   What happened

   A Pi extension (or Pi’s own tree commands) moves the session leaf with navigateTree. Pi’s JSONL leaf no longer descends through the abandoned prompts. T3 still shows those runs, leaves them completed, and keeps lastRunOrdinal on the newest T3 run.

   nativeConversationHeadRef does move to the post-rewind leaf. That part of the report is right. What stays wrong is everything that still treats later runs as live: the timeline, lastRunOrdinal, and the nativeTurnRef captured on the next turn.

   The next turn’s nativeTurnRef is the first user entry in an append-ordered get_entries window that now includes the abandoned branch. piRollbackForkEntry uses that ref as the fork entry id, so T3 Revert can re-root on an abandoned entry.

   Diagnosis

   captureTurnTreeRefs treats get_entries since: lastKnownLeaf as one forward turn. It stores leafId as the head and, unless the cursor was already marked stale, takes the first user entry in that window as the turn-start ref.

         /**
          * Locate this turn's first user entry and the new leaf in pi's session
          * tree. The user-entry id becomes the provider turn's native ref (the
          * point `fork` rolls back to); the leaf becomes the conversation head.
          * Pure bookkeeping: failures degrade to the synthetic refs.
          */
         const captureTurnTreeRefs = Effect.fnUntraced(function* () {
           const cursorWasStale = leafCursorStale;
           const cursor = cursorWasStale ? null : lastKnownLeaf;
           const data = yield* request({
             type: "get_entries",
             ...(cursor === null ? {} : { since: cursor }),
           }).pipe(Effect.orElseSucceed(() => undefined));
           // ...
           leafCursorStale = false;
           const firstUserEntryId = cursorWasStale
             ? undefined
             : Array.isArray(entries)
               ? entries
                   .filter(
                     (entry) =>
                       recordField(entry, "type") === "message" &&
                       recordString(recordField(entry, "message"), "role") === "user",
                   )
                   // ...

   leafCursorStale is set only when get_entries fails (and cleared on the next success). A successful call whose leaf jumped to an older entry is treated as a normal append. The adapter already knows get_entries is the whole tree, abandoned branches included; readThreadSnapshot uses get_messages for that reason.

   since is append order. After navigateTree, the current leaf is an older JSONL id. The next since that id returns every entry written after it, including the abandoned branch and the new prompt. The first user entry in that window is an abandoned prompt, which is how turns 6 and 7 in the report picked up 6570076c and f057ff12. A slash command that never appends a user entry leaves the rewind turn on its initial weak ref, matching turn 5.

   finalizeTurn publishes the new leaf and the (possibly wrong) turn ref. ProviderEventIngestor maps provider_thread.updated straight through. Nothing walks runs above a head that moved backward.

   lastRunOrdinal only moves forward here, on turn start:

                 yield* updateProviderThread(state, {
                   status: "active",
                   firstRunOrdinal: state.providerThread.firstRunOrdinal ?? turnInput.runOrdinal,
                   lastRunOrdinal: turnInput.runOrdinal,
                 });

   The only writer that marks runs rolled_back, checkpoints stale, and lowers lastRunOrdinal is CheckpointRollbackService, and it runs only for T3 Revert. That path calls Pi fork, which replaces the session file. navigateTree does not, so the two paths never meet.

   Clients already hide rolled_back runs. isOrchestrationV2TurnItemVisible in packages/shared/src/orchestrationV2Timeline.ts is what web and mobile projections use.

   Context usage is a smaller piece of this. The next settle reads Pi’s live get_stats, so the meter can catch up to the rewound session. The timeline and Revert target do not.

   Fix

   Detect the discontinuity in captureTurnTreeRefs: the returned leafId is not in the since window and is not the cursor. Then reconcile in orchestration, where the projection’s provider turns and run ordinals already live. Reuse the events CheckpointRollbackService writes (run.updated / node.updated → rolled_back, checkpoint.captured → stale, lastRunOrdinal lowered to the last run whose strong nativeTurnRef is still on the leaf’s parentId chain).

   Assigning the next nativeTurnRef needs the same check. Re-basing lastKnownLeaf onto the rewound leaf still leaves abandoned entries later in the file, so “first user entry since the cursor” stays wrong for the first prompt after each rewind. The turn-start id has to be a user entry that descends from the new leaf.

   No client change. A test can fake get_entries the way PiAdapterV2.test.ts already queues entries: a rewind response whose leafId is an older id, then a following turn whose window lists the abandoned user entry first.

   Workaround

   Start a new thread after a native rewind. T3 Revert on the same thread forks at nativeTurnRef, which may be an entry on the abandoned branch.

   Disposition

   Keep #13507 open. Fix it on the V2 line (the open orchestrator PR is #2829). It is not a main bug and not a duplicate.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 24, 2026
3. StiensWout

   added a commit that references this issue on Sep 30, 2026

   fix(server): Pi threads follow session rewinds made outside T3

   ...

   This issue will close once commit acf4884 is merged into the 'main' branch.

   acf4884
4. juliusmarminge commented on Oct 9, 2026

   

   juliusmarminge

   on Oct 9, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Closing this since #13839 just landed on main. It reconciles in-session Pi rewinds (like the ctx.navigateTree() repro here): T3 now walks the active leaf's ancestry, rolls back the abandoned runs and checkpoints, and skips turns that left no native entry when reverting.

   The PR lists a few known limits: detached rewinds rebaseline, extension forks aren't tracked, returning to an abandoned branch doesn't restore retired runs, and branch summaries can block rollback. If you hit one of those, please open a new issue with the repro.
5. juliusmarminge

   closed this as completedon Oct 9, 2026