Boot quiescence: stop paying ~185 rows written + ~9.7k read per hive wake

[tieguy]

The problem

initializeSchema runs in the HiveDO constructor — on every cold start / wake from hibernation, not once per deploy. Two of its steps are reconciliation (registering the kernel patterns in _objects; drop-and-recreating every audit trigger so the captured column list tracks the schema), and both ran unconditionally.

Measured on a live instance: 185 rows written and ~7.7k rows read per no-op wake. The wake rate is set by client reconnects (each MCP handshake, each /ws connect), so the cost has no relationship to actual use. On a free-tier account this consumed 90% of the 100k/day Durable Objects rows_written allowance — and 92% of the 5M/day rows_read allowance — on a day with six agent writes, then tipped over the cap entirely and took the instance down (every hive-backed route 500s once DO writes are refused). Cloudflare's hourly analytics made the attribution unambiguous: idle-hour write totals are near-exact multiples of 185 (191 = one boot, 573 = three), and reads track writes at a constant ~52.5:1 across a 50× activity range — the same cold-start population, not traffic.

The fix

Two gates, same shape as the codebase's other self-enforcing declarations:

1. bootFingerprint (stamped in _meta): derived from the kernel declarations plus the live per-pattern column signature — never hand-maintained. The _objects registration and the audit-trigger rebuild run only when it moves. Fail closed: a throw, a missing stamp, or any difference reconciles. Stored whole rather than hashed — a collision would silently resurrect the stale-trigger bug the always-rebuild deliberately fixed (a trigger built before a column existed omits it from _mutation_log forever), and an exact compare costs one row write per real schema change. evolution.ts still calls ensureAuditTriggers directly, so a live schema change never waits on a boot. Also: the _objects upsert gains WHERE … IS NOT excluded.… — SQLite rewrites the row on a no-op DO UPDATE, which billed a write per kernel pattern per wake independently of the gate.

2. runOnce (completion stamps in _completed_migrations): the pre-born-hashing token scrub was "idempotent, a near-no-op after the first cold start" — true of its writes, false of its reads: six full scans of _mutation_log (6,000 rows) on every wake forever, to re-discover there was nothing to do. A migration whose am-I-done? question is a table scan can't answer it per boot. Stamped only on success, so a part-way failure retries rather than being silently marked done. The scrub moves from hive.ts into schema.ts so the whole boot sequence is initializeSchema + applyTokenHashScrub and the oracle can measure both halves.

The oracle

boot-idempotence.test.ts counts actual rowsWritten/rowsRead through a proxied SqlStorage:

• a second consecutive boot writes zero rows (fails on any future unconditional write, whichever line introduces it);
• a quiescent boot's read count is identical at two data volumes — a property, not a threshold, so no magic constant, and any future boot-time table scan breaks it.

Verified by negative control: removing the runOnce gate fails it by name (boot reads grew with data volume (619 → 8219)).

One settling boot is allowed — reconciliation and the GC sweeps exist to do work; the pathology was paying that cost every time, forever.

The final commit regenerates the coherence artifacts with this repo's pinned v0.27 harness (my fork runs v0.31; the cherry-picked commits carried v0.31-generated artifacts).

Observed effect: boots go from 185 writes / ~7.7k reads to 0 written / ~224 read.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Rf5RTB7iigiMpoArYzdUKN