fix(replay): seed replay context cursor at recording step 1#156
Merged
Conversation
…tep+1
The dispatch shape A path was passing a.at_step as the
create_replay_context from_step, conflating two distinct concepts:
- at_step is the FORK point (controls which inherited prefix the
fork timeline shares with main, and where new recordings get
numbered)
- from_step is the cache CURSOR base (controls which recorded step
the next lookup targets)
Combined with peek_next_replay_step returning current_step + 1,
the agent's first cache lookup targeted recorded step at_step + 1.
Concrete repro on dev1 with at_step=1, session "What clusters are
running?" (3-step recording):
agent first LLM call -> lookup target = 1 + 1 = 2
step 2 is tool_call, expected LLM -> MISS
agent first tool call -> lookup target = 1 + 2 = 3
step 3 is LLM, expected tool -> MISS
Both lookups missed, the agent re-ran every step live, and the
dashboard diff rendered the entire recording as "main only" past
step at_step. Looked like the cache was broken; was actually
ordinal misalignment.
Fix: always pass 0 as from_step. Ray Serve runners (and any other
client that spawns the agent fresh per dispatch) re-execute from
scratch, so the cache must align with recorded step #1 on the
first call. The fork still inherits the at_step prefix so
operators get the "fork from step N" UX they expect; only the
cursor is decoupled from the fork point.
20 replay_jobs_tests pass including new regression
shape_a_replay_context_starts_cursor_at_recording_step_one.
Made-with: Cursor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
2 tasks
risjai
added a commit
that referenced
this pull request
Apr 28, 2026
Pulls in #156 (replay context cursor fix). v0.14.1 was tagged right after #155 merged and before #156 landed, so the cursor fix needs a fresh GitHub Release to propagate to consumers. Track 1 only (3 files: Cargo.toml + python/rewind_cli.py + python-mcp/rewind_mcp_cli.py + Cargo.lock). Python SDK stays at 0.15.1 and MCP wheel stays at 0.13.1 — neither is on PyPI yet, so the cursor fix rides with those unreleased versions. Made-with: Cursor
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Late catch from the dev1 Phase-3 validation right after #155 merged. The dispatch path was conflating two distinct concepts:
at_step— the fork point (controls which inherited prefix the fork timeline shares with main, and where new recordings get numbered).from_step— the cache cursor base (controls which recorded step the next lookup targets).Combined with
peek_next_replay_stepreturningcurrent_step + 1, the agent's first cache lookup targeted recorded stepat_step + 1. Concrete repro on dev1 withat_step=1, session "What clusters are running?" (3-step recording):Both lookups missed, the agent re-ran every step live, and the dashboard diff rendered the entire recording as "main only" past step
at_step. Looked like the cache was broken; was actually ordinal misalignment.What
Always pass
0asfrom_step. Ray Serve runners (and any other client that spawns the agent fresh per dispatch) re-execute from scratch, so the cache must align with recorded step #1 on the first call. The fork still inherits theat_stepprefix so operators get the "fork from step N" UX they expect; only the cursor is decoupled from the fork point.Validated end-to-end in dev1 by manually creating a
from_step=0context and dispatching via shape B: 3 cache hits, 0 misses, 117ms total (vs 6.3 s for the original recording — ~54× speedup).Tests
20
replay_jobs_testspass including new regressionshape_a_replay_context_starts_cursor_at_recording_step_onethat pinsfrom_step=0regardless ofat_step.Versions
No bump — workspace is already at 0.14.1 (post-#155) and v0.14.1 hasn't been released yet, so this fix rides with the unreleased version per
CLAUDE.md.Test plan
Made with Cursor