Skip to content

Coordinator WAL stops fsyncing per commit: one durability policy = NORMAL - #4781

Merged
trissim merged 1 commit into
mainfrom
claude-laptop/sync-normal
Nov 15, 2026
Merged

trissim merged 1 commit into
mainfrom
claude-laptop/sync-normal

Conversation

@trissim

@trissim trissim commented Nov 15, 2026

Copy link
Copy Markdown
Contributor

What

A single #comms send commits ~58 times across the coordinator's WAL stores (coordination 26, transcript_routes 12, registry 10, input_dispositions 8, turn_context 2). Under synchronous=FULL each commit fsyncs the WAL — 108 syncs per send measured (58 WAL + ~40 directory), the bulk of the send-burst wall time (0.3–0.8s, target <200ms).

WAL mode keeps the database file consistent at every synchronous level. NORMAL loses nothing an application/process crash could take; only an OS crash or power loss can roll a WAL back, and only to the last checkpoint. For the coordinator that is self-healing: the bus message is the source of truth and cohort acceptance is idempotent (AlreadyApplied), so a rolled-back acceptance is re-derived on the next read.

Why it was two edits, and shouldn't be

The policy was declared twice — WalStore defaulted FULL and CoordinationStore restated FULL as a literal in its own configure_connection. That duplication is the factoring defect. Collapsed to one declaration on StoreWriter (the ancestor both share) set to NORMAL: WalStore inherits it, CoordinationStore applies cls.synchronous instead of a literal. Stores that must survive power loss still override (goal stores declare EXTRA; transcript keeps NORMAL).

No migration: synchronous is a per-connection PRAGMA applied on every open, not persisted in the WAL header — a reinstall's new connections apply it.

Tests

test_coordination, test_coordination_cohort, test_carry_coordinator_wal, test_coordination_response — 85 passed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XbFMSnLEc51gw21bLFFRK1

…cy, set to NORMAL

A single #comms send committed ~58 times across the coordinator's WAL stores
(coordination 26, transcript_routes 12, registry 10, input_dispositions 8,
turn_context 2) and, under synchronous=FULL, paid one fsync per commit — the
bulk of the send burst's wall time (108 syncs/send measured).

WAL keeps the database file consistent at every synchronous level. NORMAL loses
nothing an application or process crash could take; only an OS crash or power
loss can roll a WAL back, and only to the last checkpoint. For the coordinator
that is self-healing: the bus message is the source of truth and cohort
acceptance is idempotent (AlreadyApplied), so a rolled-back acceptance is
re-derived on the next read.

The policy was declared twice — WalStore defaulted FULL and CoordinationStore
restated FULL as a literal in its own configure_connection. That duplication is
why "change the durability" looked like two edits. Collapse it to one
declaration on StoreWriter, the ancestor both share, and set it to NORMAL.
WalStore inherits it; CoordinationStore applies cls.synchronous instead of a
literal. A store that must survive power loss still overrides (goal stores
declare EXTRA; transcript keeps NORMAL).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XbFMSnLEc51gw21bLFFRK1
@trissim
trissim enabled auto-merge November 15, 2026 15:05
@trissim
trissim added this pull request to the merge queue Nov 15, 2026
Merged via the queue into main with commit 5fb2e16 Nov 15, 2026
12 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant