id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589)

Finding (from PR review, never addressed)

After a journal storage failure, new replication feeds can still receive a signed snapshot containing a mutation that was never durably committed. If FileJournal::append writes a complete entry but sync_data then fails, persist marks the actor storage-failed and publishes no update — but the ReplicationFeed handler reads the journal without checking that state, and replication_snapshot's newline check accepts the fully written but unconfirmed bytes. A newly connected replica therefore receives a terminal-committed snapshot containing the failed mutation while existing replicas stay at the previous durable cursor; a writer crash can also lose that mutation.

Raised on PR #4589:

Codex (P2), 2026-11-02T21:31:55Z: feat(id): serve signed world journal replication (#806 phase 2) #4589 (comment) — "Reject replication snapshots after a storage failure" (pkgs/id/src/world/actor.rs:1587)
CodeRabbit (Major, Data Integrity), 2026-11-02T21:37:25Z: feat(id): serve signed world journal replication (#806 phase 2) #4589 (comment) — same handler: check storage_failed before calling replication_snapshot
Related, same failure family — CodeRabbit (Minor), 2026-11-02T21:37:25Z: feat(id): serve signed world journal replication (#806 phase 2) #4589 (comment) — when journal.append bumps the header and then fails, subscribers are never told the header version went stale; the Err branch should publish ReplicationUpdate::ResetFailed when replication_header_version() changed (pkgs/id/src/world/actor.rs:421)

No-response evidence

PR feat(id): serve signed world journal replication (#806 phase 2) #4589 had a single commit; all three comments predate the merge (merged 2026-11-02T22:21:20Z as-is).
All 12 review threads on PR feat(id): serve signed world journal replication (#806 phase 2) #4589 are unresolved (GraphQL reviewThreads, checked 2026-11-03); no replies to any of these comments.

Still live on current main (verified 2026-11-03 via `gh api` raw reads)

pkgs/id/src/world/actor.rs on main, WorldCommand::ReplicationFeed handler (:1577-1591): subscribes and calls journal.replication_snapshot() with no storage_failed check.
Same file, persist (:421-425): the append Err branch sets storage_failed = true and returns without publishing ResetFailed (or any update) even when the header version changed.
pkgs/id/src/world_store.rs on main (:206-218): replication_snapshot reads the raw file and accepts any newline-terminated bytes as the snapshot.

Acceptance criteria

The replication feed refuses (or bounds snapshots to a known-durable boundary) once storage has failed.
The append-failure path notifies subscribers (e.g. ResetFailed) when the journal header version changed.
A regression test simulates an append whose sync_data fails after a complete write and shows new feeds do not receive the unconfirmed entry.
Or: a documented decision on this issue.

Found by the pr-comment-review job from unaddressed PR review comments.

🤖 Agent note · filed

Agent: pr-comment-review job
Session / ID: pr-comment-review cron run 2026-11-02 19:54 CST (2026-11-03T02:04:24Z)
Found via: unaddressed PR comment — PR feat(id): serve signed world journal replication (#806 phase 2) #4589, reviewer comment feat(id): serve signed world journal replication (#806 phase 2) #4589 (comment)
Task: Triage the validated finding: Reject replication snapshots after storage failure: ReplicationFeed handler never checks storage_failed and the append-failure path never publishes ResetFailed (Codex P2 + CodeRabbit Major/Minor on PR feat(id): serve signed world journal replication (#806 phase 2) #4589, still live on main at actor.rs:1577-1591 and :421-425)
Expectation: effort s/m — queue worker verifies against current main, then fixes or documents a decision
Links: issue id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724 · source PR feat(id): serve signed world journal replication (#806 phase 2) #4589

🤖 Agent note · handed off

Agent: opencode-claimant
Session / ID: task 6705 · ses_e5e60d15037ffe1HLSZu4zdH32
Found via: claimed repo-health queue; lane handoff confirmed
Task: Task 6705 is bound to the opencode execution lane; its worker session is launched. The worker will verify and handle the replication-snapshot storage-failure finding under issue id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724.
Expectation: repo-worker-code owns task 6705 and will report completion or a blocker through the queue helper.
Links: issue id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724

🤖 Agent note · picked up

Agent: repo-worker-code
Session / ID: task 6705 · ses_e5e60d15037ffe1HLSZu4zdH32
Found via: repo-health-code-pilot; claimed on the opencode execution lane
Task: Re-verified issue id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724 against the current checkout and fresh GitHub state. The unguarded replication snapshot handler and silent append-error branch are still present; I’m adding a regression that models a complete write followed by sync failure.
Expectation: verify the fix with targeted Rust tests, then open a PR for id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724.
Links: id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724 · feat(id): serve signed world journal replication (#806 phase 2) #4589

Merge pull request #4738 from developing-today/queue/6705-4724-replic…

🤖 Agent note · completed

Agent: repo-worker-code
Session / ID: task 6705 · ses_e5e60d15037ffe1HLSZu4zdH32
Found via: repo-health-code-pilot; task claimed on the opencode execution lane
Task: Re-verified the storage-failure finding on current main, reproduced the leaked snapshot, then fixed and tested it. Replication feeds now refuse once storage failed; append failures publish ResetFailed if the journal header version changed.
Outcome: merged PR fix(id): refuse replication feeds after storage failure (#4724) #4738 (cf74b1ea179804fe378542592d1bcde83480afd4).
Verification: replication_feed_tests — 4 passed; rustfmt 1.99.0 check and git diff --check passed.
Links: fix(id): refuse replication feeds after storage failure (#4724) #4738 · id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724

Navigation Menu

Repository navigation

id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724

Finding (from PR review, never addressed)

No-response evidence

Still live on current main (verified 2026-11-03 via `gh api` raw reads)

Acceptance criteria

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id(world-replication): new feeds can receive a snapshot containing a storage-failed, never-durable mutation (PR #4589) #4724

Description

Finding (from PR review, never addressed)

No-response evidence

Still live on current main (verified 2026-11-03 via gh api raw reads)

Acceptance criteria

Activity

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Still live on current main (verified 2026-11-03 via `gh api` raw reads)