mosaicstack/stack
1
0
Fork 0
Code Issues 85 Pull Requests Actions Packages Projects Releases 15 Wiki Activity

wake/store hardening (low-pri, def-in-depth): gate the final observed_seq cursor write in cmd_enqueue #917

New Issue
Closed
opened 2026-07-26 05:35:59 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-07-26 05:35:59 +00:00
Owner
Copy Link

Defense-in-depth hardening surfaced by the independent review of #915 (store-side allocator unification; RoR reviewer aab36467). NON-BLOCKING, low priority, pre-existing.

Observation. In store.sh cmd_enqueue, the final observed_seq cursor _atomic_write is the ONE durable write not wrapped in a failure check, and it is cross-file non-atomic with the observed.set write immediately before it. Practically unreachable — all three are same-dir atomic (tmp+rename) writes, and the cursor write is textually LAST and only reached if the pending + observed.set writes succeeded (so a failed pending write cannot burn a seq; that arrow-#1 property is proven by test T9). This is strictly BETTER than the pre-#908 code (which had all three writes ungated); #908 added gating to pending + observed.set.

Suggested hardening (defense-in-depth, no known trigger): gate the final cursor _atomic_write too (check its exit), and/or make the observed.set + cursor advancement a single atomic step, so that even a cursor-write failure after a successful pending write cannot leave observed.set and the cursor cross-file inconsistent.

Priority: LOW. Refs: #908 / PR #915, §2.4 cursor semantics.

Defense-in-depth hardening surfaced by the independent review of #915 (store-side allocator unification; RoR reviewer aab36467). NON-BLOCKING, low priority, pre-existing. **Observation.** In store.sh cmd_enqueue, the final `observed_seq` cursor `_atomic_write` is the ONE durable write not wrapped in a failure check, and it is cross-file non-atomic with the `observed.set` write immediately before it. Practically unreachable — all three are same-dir atomic (tmp+rename) writes, and the cursor write is textually LAST and only reached if the pending + observed.set writes succeeded (so a failed pending write cannot burn a seq; that arrow-#1 property is proven by test T9). This is strictly BETTER than the pre-#908 code (which had all three writes ungated); #908 added gating to pending + observed.set. **Suggested hardening (defense-in-depth, no known trigger):** gate the final cursor `_atomic_write` too (check its exit), and/or make the observed.set + cursor advancement a single atomic step, so that even a cursor-write failure after a successful pending write cannot leave observed.set and the cursor cross-file inconsistent. Priority: LOW. Refs: #908 / PR #915, §2.4 cursor semantics.
Mos closed this issue 2026-07-26 15:14:39 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#917
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?