Repository navigation
Mixed-version writes erase Round.CoBots, dropping co-reviewer trigger claims #37
Description
Activity
- added 4 commits that reference this issue
on Jul 25, 2026 Closed in effect by the version tolerance (#43) plus schema v4 (#55), now released as crq 2.0.0.
RoundandStateround-trip JSON members they do not recognise (internal/state/tolerant.go), so a binary that writes state no longer erases fields it has never heard of —CoBotsincluded. That removed the mechanism this issue describes for every additive field from v3 onward.What it could not do is protect against a binary older than the tolerance itself, and that happened here on 2026-07-27: a crq from before
tolerant.goshared the ref and wipeddispatch,drain,writersandcobotsfrom every round.crq doctornow reports other crq installs on the host, compared by content, because the version string cannot tell two builds apart.Schema v4 closes the remaining gap the hard way: an older binary now refuses the payload instead of writing a lossy one (#49). The cost is that every host must be upgraded together, which is stated in the README's environment table.
Leaving this open only if you want the Codex dual-write removed —
foldLegacyCodexis still legacy-authoritative in both directions, which is the last thing here that exists for mixed versions.
Split out of the review of #35, where it was raised three times. The mechanism is real; it is documented there as a rollout requirement rather than solved in code, and this issue is the place to solve it properly.
The mechanism
Round.CoBotsis additive on schema v3, so an old binary reads the state fine. But Go'sencoding/jsondrops unknown fields, so an old binary that writes state marshals the round withoutcobots— erasing every Bugbot/Macroscope command id and CAS claim the new binary recorded.Blast radius
Narrower than it looks, and worth stating precisely so this is not over-fixed:
FireSlotplusCommandID, both legacy fields old binaries preserve. Codex is dual-written intoCodexCommandID/CodexCommandedAt/CodexClaimedAtfor exactly this reason.observenarrows it further: the next pass sees the already-postedbugbot runon the PR and suppresses a repost. The exposed window is between claim and post — seconds — not the claim's lifetime.Why not just bump the schema
Considered and rejected: an old binary meeting a version it does not know auto-reinitialises the shared state, losing every round in the fleet rather than one map — and it would do so during exactly the rolling deployment this is about. That trades a bounded loss for an unbounded one.
Current mitigation
Documented in #35 under "Rollout requirement": upgrade the whole fleet before enabling Bugbot or Macroscope.
Possible approaches
json.RawMessageand re-emit), which fixes this class of problem generally rather than forCoBotsalone.