You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ax exec --last-seq <n> flag is accepted by the CLI and sent on the wire, but the controller never reads ExecRequest.LastSeq. A disconnected client that reconnects with --last-seq does not get the events it missed replayed; the field is silently ignored.
Evidence
Client sets it: cmd/ax/exec.go (--last-seq flag → ExecRequest.LastSeq).
Proto field exists: proto/ax.proto (int32 last_seq = 3;).
No server-side reader: LastSeq / GetLastSeq() has zero non-test references anywhere under internal/ (including internal/controller/). Controller.Exec resumes purely from conversation state via ResumptionState, never filtering/replaying by sequence.
The recent controller rewrite in #308 ("Handle default harness correctly") replaced tryResuming/ResumptionState, and the last_seq handling was dropped in the process.
Impact
Disconnect/reconnect replay is broken: a client that saw up to seq N and reconnects with --last-seq N still cannot backfill the events it missed while a conversation was in flight.
The flag is effectively dead: it is documented and accepted but has no effect.
Repro
Start a conversation and note the last seq printed.
Observe the missed events between <n> and the current head are not replayed.
Expected
Either:
Restore server-side last_seq handling so the controller replays events with seq > last_seq (as in ConversationEvent.harness_config should be bytes #262), returning a clear error when last_seq is not in the event log; or
If the field is intentionally deprecated, remove it from the CLI/proto and update docs.
Notes
Docs corrected in #319 (README no longer promises the replay behavior) while this code gap is open. Related historical discussion: #7 (closed).
Summary
The
ax exec --last-seq <n>flag is accepted by the CLI and sent on the wire, but the controller never readsExecRequest.LastSeq. A disconnected client that reconnects with--last-seqdoes not get the events it missed replayed; the field is silently ignored.Evidence
cmd/ax/exec.go(--last-seqflag →ExecRequest.LastSeq).proto/ax.proto(int32 last_seq = 3;).LastSeq/GetLastSeq()has zero non-test references anywhere underinternal/(includinginternal/controller/).Controller.Execresumes purely from conversationstateviaResumptionState, never filtering/replaying by sequence.Regression
Server-side
last_seqhandling used to exist:last_seen_seq→last_seqev.Seq > req.LastSeq) intryResumingThe recent controller rewrite in #308 ("Handle default harness correctly") replaced
tryResuming/ResumptionState, and thelast_seqhandling was dropped in the process.Impact
--last-seq Nstill cannot backfill the events it missed while a conversation was in flight.Repro
seqprinted.ax exec --conversation <id> --last-seq <n> --resume.<n>and the current head are not replayed.Expected
Either:
last_seqhandling so the controller replays events withseq > last_seq(as in ConversationEvent.harness_config should be bytes #262), returning a clear error whenlast_seqis not in the event log; orNotes
Docs corrected in #319 (README no longer promises the replay behavior) while this code gap is open. Related historical discussion: #7 (closed).