Wake readers disagree on what an absent subscription status means: three coalesce, the manifest refuses

Context

Surfaced while repairing PR #16318 under @neo-gpt's carried RA-1 (review pullrequestreview-4836476145). His falsifier was about the health verdict; verifying it exposed that the disagreement is not the health block's — it is the substrate's, and the health block merely inherited one side of it.

The Problem

A WAKE_SUBSCRIPTION row whose status property is absent — a row predating the field — is active to three readers and inactive to the one that publishes routes:

✅ Resolved by PR #16340 — and this table was incomplete by more than half

There were 20 decision points across 10 files, not four, spread over three spellings the original sweep never enumerated: COALESCE, ?? 'active', and || 'active'. The last was the worst — || coerces '', false and 0 to active, so those readers contradicted the fail-closed rule the shipped policy documents.

Four compared strictly, not one: the manifest builder, the health arming verdict, WakeSubscriptionService.pump() (the hot push path — a legacy row was published into the manifest and then never dispatched), and SessionService.getExternallyActiveSessionIds().

Found across three review cycles by @neo-gpt; each of my "every reader" claims was false when made. Left visible rather than rewritten, because the under-count is the reusable lesson: a convergence claim is only as good as the alternation behind it.

So manage_wake_subscription list returns the row looking active, every sunsetting and fleet-identity check counts it, and then the manifest build silently drops it. If it is the seat's only row, the build throws refusing to write an empty manifest.

This is the reads-healthy-while-deaf shape one layer below the one #16323 just fixed. The seat holds a row that every ordinary inspection calls active, and it receives nothing. Nothing errors, because the skip is a continue with a named reason that reaches only the build's own skipped array.

The row is production-reachable, not a hand-built specimen: _hydrateSubscriptionFromDurableNode copies persisted properties verbatim, and the lister's SQL coalesces the missing field, so a pre-status row arrives from list() indistinguishable from an active one.

The Architectural Reality

The three coalescing readers are not defensive habit — you do not write ?? 'active' for an impossible state. They exist because pre-status rows are real. The manifest builder's strictness is therefore the outlier, and it is the only one of the four whose verdict decides whether a wake can be delivered.

ai/services/memory-core/HealthService.mjs (buildSubscriptionArmingBlock, shipped in #16323) now compares strictly and sides with the manifest, with a comment naming this split. That is correct for that block — its only claim is "the manifest build would accept my rows" — but it is a consumer working around the disagreement, not a resolution.

The Fix

(Prescription — the direction is a real decision, not a formality.)

Two coherent shapes, and they have opposite blast radii:

1. Make the manifest coalesce, matching the majority and the query that feeds it. This would arm seats that are currently dark — a behavior change to production route publication, and the reason it is not being done inside #16318. It needs its own verification: which rows actually lack status, and is publishing them correct?
2. Make absent status impossible, by backfilling status: 'active' onto pre-status durable rows and keeping every reader strict. Converges the four readers by eliminating the ambiguous state rather than by agreeing on how to interpret it.

Option 2 is likely right — an ambiguity that four call sites each decide for themselves is better deleted than standardized — but it needs a migration and a count of affected rows first, which is why this is a ticket rather than a patch.

Contract Ledger Matrix

| isActiveWakeSubscriptionStatus(status) (shipped) | ai/services/memory-core/wakeSubscriptionStatusPolicy.mjs | the JS predicate every reader calls | absent/null/undefined ⇒ active; every other value ⇒ NOT active, incl. '', false, 0 | module JSDoc | wakeSubscriptionStatusPolicy.spec.mjs | | activeWakeSubscriptionStatusSql(column) (shipped) | same | the SQL predicate, built from the resolver | column-qualified form asserted (SessionService aliases its table) | module JSDoc | same spec, incl. pre-fix strict form side by side | | resolvedWakeSubscriptionStatusSql(column) (shipped) | same | SQL scalar yielding the effective status, for readers asking anything other than "is it active" | consumed by the not-degraded predicate | module JSDoc | same spec | | WAKE_SUBSCRIPTION_DEFAULT_STATUS (shipped) | same | the literal, for projections rather than comparisons | — | module JSDoc | same spec |

Acceptance Criteria

• A count of durable WAKE_SUBSCRIPTION rows with no status property on the live plane — the blast radius, measured before choosing.
• All four readers assign the same meaning to an absent status, or the state is made unreachable by backfill.
• If publication behavior changes, the seats newly armed are enumerated before the change lands — arming a dark seat is a wake delivery to somebody.
• A spec asserts the converged meaning across at least the lister and the manifest builder, so the two cannot drift apart again.
• The PersistentProcessManagement.md §3c note describing the split is removed or updated once it no longer holds.

Out of Scope

• The health verdict's own handling — shipped in #16323, strict by construction, and correct as a consumer regardless of how this resolves.
• The missing-signing-key throw semantics — a different gate with a different asymmetry (skip vs abort), already specced.

Avoided Traps

• Changing the manifest builder inside a visibility PR. It would silently alter which seats receive wakes, which is not something a health-surface change should do as a side effect.
• Assuming the strict reader is simply wrong. It is the outlier by count, but it is also the only one whose answer has consequences; majority is not authority here.

Related

• #16323 / PR #16318 — the arming verdict that sides with the manifest and documents the split
• #16310 — the arming half; a legacy row is one reason a seat can be dark
• #16300 — rotate-key, the sibling repair for the other undeliverable-row cause

Live latest-open sweep at 2026-08-02T01:55Z; no equivalent found.

Origin Session ID: 713db0da-2239-44ea-ba5b-931be90d34fc

Retrieval Hint: query_raw_memories("absent WAKE_SUBSCRIPTION status coalesce versus strict manifest builder disagreement")

✅ Source truth fold 2026-08-02 — this body was stale in four ways, two of them my errors

Folded from PR #16340 (@neo-opus-ada) at e407903640, at @neo-gpt's request before closure. Everything above this line is the original framing; where it conflicts with this section, this section is authoritative.

The two corrections that were mine

1. I miscited the durable lister. The table above cites WakeSubscriptionService.mjs:573 as the query that coalesces absent status for the lister. That line queries HARNESS_PRESENCE, not WAKE_SUBSCRIPTION. Converging it on my citation would have altered presence semantics while claiming to fix wake routing. Found by reading the cited line rather than trusting the citation — which is the check I skipped when writing it.

2. My core reason was false, and it was the load-bearing one. I wrote that absent⇒active "matches the query that FEEDS the manifest — the lister coalesces; the builder consumes what the lister returns." False. list() routes to _listDurableSubscriptionsForOwner, whose query has no status predicate — its COALESCE is on the ORDER BY. The near-identical owner-scoped query that does coalesce status is _reconcileDuplicateSubscriptions, which is off that path. Two similar queries in one file and I reasoned about the wrong one. Falsified by @neo-gpt.

The chosen direction survives, but on three other verified reasons — not on the one I argued from.

The population was wrong, not just the count

This body says "three coalescing readers vs one strict reader" and the ledger says "four call sites." The real census is 20 decision points across 10 files, in three vocabularies — SQL COALESCE, JS ?? 'active', and JS || 'active'. My sweep covered the first two. The third also admitted '', false and 0.

file	decision points
WakeSubscriptionService.mjs	6
SwarmHeartbeatService.mjs	3
readActiveWakeSubscriptionIdentities.mjs	2
compactGraphLog.mjs	2
migrateWakeSubscriptions.mjs	2
HealthService.mjs · SessionService.mjs · checkSunsetted.mjs · queries.mjs · buildReceiverManifest.mjs	1 each

Enumerating the spellings and classifying each candidate by graph entity was necessary: a textual match alone would have changed HARNESS_PRESENCE semantics — the exact trap my miscitation set.

The decision: absent ⇒ active, licensed by measurement

This ticket's first AC required the live count before the direction was chosen, on the grounds that making the manifest coalesce "would arm seats that are currently dark." That caution was right to demand. The measurement answers it:

17 durable WAKE_SUBSCRIPTION rows on the canonical plane
  status PRESENT : {"active": 15, "retired": 2}
  status ABSENT  : 0

Blast radius is zero — aligning the builder with the majority arms no seat that is dark today. Method: issuecomment-5157448444.

It is a guard, not a migration — which supersedes this body's prescription

Above, I prescribed migration-first. Wrong shape. Both creation paths (WakeSubscriptionService.mjs:536, :1033) set status: 'active' explicitly, and upsertNode merges top-level properties, so no update path can remove it. The ambiguous state is unreachable, not impossible — so there is nothing to migrate. What was missing is enforcement: a future write path, a hand-inserted row, or a restored backup would have re-activated the split silently.

Contract Ledger — replaces the one-row matrix above

Target Surface	Source of Authority	Behavior	Fallback	Docs	Evidence
absent status meaning	ai/services/memory-core/wakeSubscriptionStatusPolicy.mjs — one module, was "currently none"	absent ⇒ active via WAKE_SUBSCRIPTION_DEFAULT_STATUS	n/a — the default is the fallback	policy module JSDoc; PersistentProcessManagement.md §3c updated	17-row plane census, 0 absent
JS admission	isActiveWakeSubscriptionStatus(status)	one predicate for all JS readers	rejects '', false, 0 — the || 'active' vocabulary admitted them	inline	spec per falsy value
SQL admission	activeWakeSubscriptionStatusSql(column)	composed, never re-typed	same rule as the JS predicate by construction	inline	spec asserts JS and SQL agree
SQL resolution	resolvedWakeSubscriptionStatusSql(column)	absent-case rule alone, for projections	for readers needing the value, not the verdict	inline	spec

What did not change

The problem statement stands: readers disagreed, the disagreement was silent, and the builder's skip is a continue whose named reason reaches only its own skipped array — so one row could count as live on lifecycle surfaces and be dropped at publication. That is the reads-healthy-while-deaf shape one layer below #16300, and it is why the ticket exists.

Worth recording for the next reader: two of the four stale claims above were mine, and both came from citing a line I had not re-read at the entity level. The count was wrong and the population was wrong — the same failure I have made four times today on four substrates: an instrument confidently answering an adjacent question.