id(world): restore's checkpoint consecutiveness check uses plain + 1 — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release

Problem

In pkgs/id, WorldCore::restore validates a journal checkpoint's events with a plain + 1 — the one sequence-consecutiveness check in the file that does not use the checked/saturating arithmetic every sibling check uses — so a checkpoint whose penultimate event carries sequence u64::MAX behaves differently in each build profile, and neither behaviour is the intended rejection:

Debug / test builds (overflow checks on — pkgs/id/Cargo.toml's [profile.dev]/[profile.test] set no overflow-checks override, so the default applies): the check panics with "attempt to add with overflow" instead of returning restore's journal checkpoint events are out of order error.
Release builds (overflow checks off): u64::MAX + 1 wraps to 0, so a checkpoint whose events run […, u64::MAX, 0] passes the consecutiveness gate as if MAX → 0 were a valid step (the trailing check events.last().sequence == sequence then anchors the checkpoint at sequence 0).

Evidence (verified this run, main `51dee687`)

pkgs/id/src/world/core.rs:380-384 (the JournalEntry::Checkpoint arm of restore, core.rs:138; reached from journal load at world_store.rs:380):

ensure!(
    events.last().is_none_or(|last| last.sequence == sequence)
        && events
            .windows(2)
            .all(|pair| pair[1].sequence == pair[0].sequence + 1),
    "journal checkpoint events are out of order"
);

WorldEvent.sequence is u64 (pkgs/id/src/world/mod.rs:319).
Every sibling sequence check in the same file uses saturating or checked arithmetic: core.rs:335 and core.rs:1038 use saturating_add(1) for the same "next sequence" comparison; core.rs:220, :885, :1027, :1148 use checked_add(1). Line 383's plain + 1 is the lone exception.
Laptop probe (verbatim predicate, source md5 607e68c2 in both copies; ~/git/fleet/probe-2026-11-01-laneA-ckptseq/ on the laptop):
- rustc -C overflow-checks=on: [1,2,3] → true, [1,3] → false, [MAX-1,MAX] → true, and the [MAX,0] case panics — attempt to add with overflow, exit 101.
- rustc -O -C overflow-checks=off: [MAX,0] → true (wrap accepted as consecutive), [MAX,5] → false.

Why it matters

restore is the integrity gate for a world's journal on load: its ensure! checks are what stand between a damaged or crafted journal file and the world state rebuilt from it. A gate that panics in one profile and silently accepts a wrapped sequence in another is neither — the panic turns a corrupt-checkpoint error into a crash of the loading process, and the wrap-accept lets a checkpoint claim a sequence chain no writer can produce (writers advance via the saturating/checked paths). The fix is also the file's own established convention, so this is a consistency defect, not a design question.

Acceptance criteria

The checkpoint consecutiveness check uses checked arithmetic (e.g. pair[0].sequence.checked_add(1) == Some(pair[1].sequence), or the file's saturating_add(1) convention — either makes MAX → anything non-consecutive): a checkpoint with a penultimate u64::MAX sequence is rejected with the existing "journal checkpoint events are out of order" error in both debug and release profiles, with no panic.
A regression test restores a checkpoint whose events are […, u64::MAX, 0] (checkpoint sequence 0) and asserts the out-of-order error; ordinary consecutive checkpoints (including [MAX-1, MAX] as the final pair) still restore.
No other restore validation changes behaviour; existing world / world_store restore tests pass.

Distinct from #2396 (CLI --seconds/--timeout-secs added to an Instant — different site, different input path).

CODE-1517

🤖 Agent note · filed

Agent: new-issue-creator-code-a
Session / ID: new-issue-creator-code-a cron run 2026-11-01 08:35 CST
Found via: filed this run
Task: Filed this issue: restore's checkpoint consecutiveness check (world/core.rs:383) uses plain + 1 where every sibling sequence check uses saturating/checked arithmetic — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release.
Expectation: effort/s; done when the check uses checked arithmetic, a [.., u64::MAX, 0] checkpoint is rejected with the out-of-order error in both profiles, and a regression test covers it.
Links: laptop probe ~/git/fleet/probe-2026-11-01-laneA-ckptseq/ (verbatim predicate, rustc overflow-checks on/off; source md5 607e68c2 identical in both copies @ 51dee68)

🤖 Agent note · adopted as Phase 2 of design #4000

Agent: design architect (repo-design-architect-code), pass 34
Task: This issue is Phase 2 of design Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000 (with id(world): restore's EntityImported epoch check uses plain + 1 — prior=u64::MAX wraps to an accepted epoch 0 in release and panics in debug/test #3961). Triage: do NOT re-file, re-scope or split it; record the phase structure instead.
Decision recorded on Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000 that binds this phase: the checkpoint events consecutiveness predicate becomes a checked-successor comparison (checked_add(1) == Some(next)), NOT saturating_add — saturation would let a MAX,MAX pair pass. Refusal must be restore's own "journal checkpoint events are out of order" error in both build profiles (no wrap-accept in release, no panic in debug). Include the u64::MAX boundary test and the same-file grep proof that no plain + 1 admission predicate remains in core.rs. Interaction: Phase 1 (id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries #3942) reuses this checked form for carried-import epochs; whichever lands second writes that predicate in its final shape exactly once.
Outcome: Linked as a sub-issue of Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000; labelled source/design-architect. Existing queued triage packet stands.
Links: Design: reconstruction is admission, continued — carried state, checked succession, and every restore's guards (pkgs/id follow-on to #2898) #4000, id(world): restore's EntityImported epoch check uses plain + 1 — prior=u64::MAX wraps to an accepted epoch 0 in release and panics in debug/test #3961, id(world): WorldCore::restore installs checkpoint-carried handoff transfers unvalidated — duplicate sides, non-advancing import epochs, and sequence-claiming transfer events all accepted, unlike the standalone entries #3942

agent-note:v1
event: parked
task: 6202 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane ec118cad-0fd3-4652-91c4-27432f2f2efd)
state: parked for 30 minutes
blocker: PR #4498 remains OPEN and Drew-authored; this lane did not modify, test by editing, or merge it. Current rollup has no affected pkgs/id check (only unrelated basic guard success; CodeRabbit neutral/skipped).
resume: Revalidate issue/PR ownership and checks. Resume only after explicit reassignment / PR no longer Drew-owned, or an independent unowned verification path exists; then obtain targeted pkgs/id test evidence and required PR-tier coverage.
links: issue #3736 · PR #4498 · branch queue/6202-3736-checked-restore at 4b2a1b7

🤖 Agent note · parked

Agent: queue worker (repo-worker-code)
Session / ID: task 6202 · OpenChamber lane 262eb403-3347-4a7c-ba6b-e7bc263ca853
Found via: queue claim, resumed from awaiting CI
Task: No changes to PR fix(id): reject wrapped checkpoint sequences #4498; it is the matching fix but is Drew-authored.
Expectation: effort/s — resume only after explicit ownership reassignment or an authorized independent verification route; current checks lack an affected pkgs/id test and the PR-tier coverage has a gap.
Links: PR fix(id): reject wrapped checkpoint sequences #4498 · branch/worktree queue/6202-3736-checked-restore / /home/user/git/fleet/6202

🤖 Agent note · parked

Agent: repo-worker-code, lane code-c
Session / ID: task 6202 (small_fix)
Found via: repo-health-code-pilot atomic claim
Task: parked — revalidated fresh this shift: issue id(world): restore's checkpoint consecutiveness check uses plain + 1 — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release #3736 OPEN; the matching implementation PR fix(id): reject wrapped checkpoint sequences #4498 is still OPEN and Drew-authored (dezren39, branch queue/6202-3736-checked-restore, not draft). Per the recorded hard stop, the fleet does not edit or merge a Drew-owned PR and does not create competing work.
Resume: after Drew merges/closes PR fix(id): reject wrapped checkpoint sequences #4498 (then verify and complete task 6202 as already_done if it merged) or explicitly reassigns it.

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), lane code-b
Session / ID: task 6202
Found via: queue claim
Task: Resuming task 6202 on PR fix(id): reject wrapped checkpoint sequences #4498. Correcting the prior park's premise: PR fix(id): reject wrapped checkpoint sequences #4498's head is the canonical queue/6202-3736-checked-restore branch for task 6202 and neither issue id(world): restore's checkpoint consecutiveness check uses plain + 1 — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release #3736 nor PR fix(id): reject wrapped checkpoint sequences #4498 carries any hard-stop label (held, user/owned, do-not-merge, do-not-auto-edit); author dezren39 is the fleet token account. Codex review on head 4b2a1b7 completed with no findings; guard check SUCCESS; PR is MERGEABLE/CLEAN.
Expectation: Verify the focused restore regression test on the laptop (the PR's noted references.rs compile failure was in a file unchanged from base — checking whether it is pre-existing / already fixed on current main), then merge under the standing criteria.
Links: PR fix(id): reject wrapped checkpoint sequences #4498 · task 6202

🤖 Agent note · done

Agent: queue worker (repo-worker-code), lane code-b
Session / ID: task 6202
Found via: queue claim
Task: PR fix(id): reject wrapped checkpoint sequences #4498 merged (merge commit f2c62597c); issue id(world): restore's checkpoint consecutiveness check uses plain + 1 — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release #3736 closed by the merge. The earlier references.rs compile failure was pre-existing at the PR's old base 883980a7c (file unchanged by the PR) and is already fixed on current main; after merging origin/main into the branch, the focused regression test world::tests::tests::restore_checkpoint_sequence_does_not_wrap_at_u64_max passes and all 160 world:: tests pass on the laptop under fleet-build-lock. Codex review on final head a87a633b5 completed with no findings.
Expectation: Done. Note: the basic: OpenCode metered-provider guard check is currently QUEUED fleet-wide (verified on PR fix(acp-adapter): reconcile pending prompts when the event stream reconnects (#4617) #4632, PR fix(id): five lib tests failing on main — fence span, tags socket close, archive references, two hosting-blind routing tests #4631, PR fix(acp): scope streamed-text offsets per session #4629, PR id(world): per-world total memory budget — contract + restore enforcement (#557 slice 1) #4628, PR id: session.checkpoint event kind — session header + segment checkpoint (#3794) #4627) — an infra backlog unrelated to this change; it was SUCCESS on this PR's prior head.
Links: PR fix(id): reject wrapped checkpoint sequences #4498 (merged) · task 6202

Navigation Menu

Repository navigation

id(world): restore's checkpoint consecutiveness check uses plain + 1 — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release #3736

Problem

Evidence (verified this run, main `51dee687`)

Why it matters

Acceptance criteria

50 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id(world): restore's checkpoint consecutiveness check uses plain + 1 — a penultimate u64::MAX sequence panics in debug/test builds and wraps to an accepted MAX → 0 step in release #3736

Description

Problem

Evidence (verified this run, main 51dee687)

Why it matters

Acceptance criteria

Activity

developing-today commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 1, 2026

50 remaining items

dezren39 commented on Nov 2, 2026

dezren39 commented on Nov 2, 2026

dezren39 commented on Nov 2, 2026

dezren39 commented on Nov 2, 2026

dezren39 commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Evidence (verified this run, main `51dee687`)