open-pool claiming may be silently degraded under access-scoped relay REQs — seller has zero CLOSED observability

[orveth]

Split out from #171 (marketplace-level, independent of the reconnect wedge).

The relay (buzz e18020a63) now access-scopes global/channel-less REQ results and emits NIP-01 CLOSED on rejected subscriptions. Two consequences for sellers running broad open-pool filters (claim_open_pool):

1. Silent degradation: if a broad filter is rejected or its results scoped down, the seller can be limited to targeted offers (or deaf entirely) while still heartbeating accepting=true — buyers see a live seller that never claims.
2. Zero observability on the seller node: the notification loop handles only Event and Shutdown — no Message/Closed arm — so a CLOSED subscription is dropped by the SDK with no log line and no re-subscribe. The pre-cutover binary at least had a loud, offer-sub-specific fallback (degrade to #p==self + log; seller_daemon/mod.rs:4160ff).

Current field datum (weak but real): the old-binary fleet's broad REQs appear to be accepted under scoping (offers received post-flip, zero fallback fires), so this may not be biting today — but nothing on dev would tell us if it started.

Asks:

• Restore CLOSED observability on the seller node (part of seller node: in-process relay reconnect never re-authenticates (NIP-42) — fresh boot always works #171's fix — port the fallback semantics, extended beyond the offer sub).
• Add a periodic subscription-liveness self-check (e.g. the seller's own heartbeat round-trip already proxies this; assert offers-sub liveness distinctly).
• Document the relay's access-scoping contract for marketplace clients (which filters are scoped/rejected and how a client should detect it).

[orveth]

Design note for the liveness self-check (from the operator who has been performing it by hand all evening):

The existing stall detector already IS a subscription-liveness check — but only for the heartbeat subscription (it fires on own-heartbeat round-trip failure). That's exactly why the dropped-fallback class is invisible to it: the heartbeat sub stays alive while the offer sub has been CLOSED and removed, so the seat reports accepting=true in perfect good faith while deaf. Any "did an event arrive recently" check inherits that blind spot per-subscription and can't distinguish a dead subscription from a quiet market.

The check should be positive and per-subscription, not traffic-based: keep the set of subscription ids the node believes it holds; on a timer, reconcile against what the pool actually has. A registered id no longer present was dropped by the relay (nostr-sdk won't re-subscribe it) → log WHICH one and re-subscribe. Needs no traffic to flow; covers awards/1059/heartbeat subs that even the old fallback didn't.

It composes with (not duplicates) the CLOSED arm: the arm reacts immediately to a seen frame; the reconciler is the backstop for a missed frame or one that arrived before the arm was listening. The reconciler should log the discrepancy even when it re-subscribes successfully — tonight's core lesson was that a silent self-heal made two fleets' evidence uninterpretable.

Two cheap additions for the same slice:

• Expose the current subscription set in the seat's status surface, so an operator can answer "am I actually subscribed?" without reading source.
• Have the heartbeat carry subscription health, not just accepting=true — which currently claims "I would accept work if I heard about any," not "I can hear."

[orveth]

Affected population pinned + a grandfathering effect that hid this for 18 hours (old-binary fleet analysis):

• The affected population is precisely claim_open_pool = true sellers: the old binary adds the unpinned open-pool filter into the grouped offer REQ only under that flag (targeted #p==self always present). And the two binaries fail differently: old degrades loudly to targeted-only and keeps earning on targeted work; dev goes silently deaf while heartbeating accepting=true. The difference between a degraded seller and a lying one.

• Grandfathering effect: access-scoping is evaluated at REQ time. Long-lived daemons whose subscriptions were registered under the previous relay build (pre-flip) are still served under the old rules — two seats have carried the broad open-pool filter for ~18h post-flip with zero CLOSED frames, because they never re-presented it. Every such seller is one restart/reconnect away from hitting the new rules for the first time. Fleet health after a relay contract change is therefore NOT evidence the contract change is benign.

• A targeted probe offer (arrives via #p==self) validates only the targeted branch — it cannot detect open-pool deafness. Detecting that needs an untargeted post, or the mechanism confirmed directly.

• A controlled split experiment is running on the old fleet: bounce ONE claim_open_pool=true seat at queue_depth=0 → it re-presents the broad filter under the new rules for the first time. CLOSED + loud fallback = mechanism confirmed (and simultaneously proves the relay emits CLOSED for broad filters — the open wire question). Clean re-REQ = mechanism refuted. Result to follow on seller node: in-process relay reconnect never re-authenticates (NIP-42) — fresh boot always works #171/open-pool claiming may be silently degraded under access-scoped relay REQs — seller has zero CLOSED observability #172.

[orveth]

Structural confirmation (dev source): CLOSED is invisible to the seller node by construction.

seller_node/run.rs notification loop (~L550–569) matches only RelayPoolNotification::Event and ::Shutdown. A relay CLOSED frame arrives as a ::Message — there is no Message arm, and a grep of mobee-core shows zero relay-CLOSED handling anywhere (every "Closed" hit is PaymentState or fail-closed money semantics).

Full chain: relay access-scopes the open-pool broad REQ → emits CLOSED(restricted:) → nostr-sdk treats restricted: as Remove, drops the sub, never re-subscribes → the node's loop has no arm that could observe any of this → open-pool subscription silently gone, accepting=true persists. Not "fails to degrade loudly" — never receives the signal to degrade. The targeted #p==self sub isn't access-scoped, which is why a targeted probe at the affected seat can't detect this.

Corroboration: all three dev field seats are claim_open_pool=true, have re-REQ'd many times under the new relay build, and log zero CLOSED/WARN/degrade lines — consistent, since no code path could emit one.

Fix shape confirmed: add the ::Message arm (inspect CLOSED → loud log + degrade/re-subscribe per the ported fallback), with the per-subscription reconciler as the backstop for missed frames.

Instrument note (pre-registered before results land): a foreign-targeted offer reaches a NON-target seat only via that seat's open-pool filter. So the running targeted probe doubles as an open-pool liveness test for every observing dev seat: an observing seat logging the foreign-offer skip = its open-pool branch alive; silence (with the offer confirmed on-relay) = open-pool deafness demonstrated live. And if the separately in-flight targeted trade's offer fails to arrive at its target seat, that would implicate the whole grouped REQ rather than just the broad half.

[orveth]

Rescope after the split experiment (#171 latest): access-scoping is NOT currently rejecting mobee's open-pool filter — a fresh broad REQ under e18020a63 was accepted and is demonstrably serving untargeted offers. So the correct scope for this issue is the narrower, still-real defect:

"The seller node cannot see CLOSED at all" (no ::Message arm), NOT "CLOSED is eating open-pool subscriptions today."

The fix asks stand unchanged (Message/CLOSED arm with loud degrade semantics, per-subscription reconciler backstop, status surface, heartbeat carrying subscription health) — they're insurance against the day the relay's scoping DOES touch this filter shape, plus general subscription-lifecycle observability. What changes is urgency: this is hardening, not an active outage. Field note: a dev seat's zero-CLOSED-lines cannot distinguish "no CLOSED arrived" from "arm doesn't exist" — which is itself the strongest argument for the reconciler's positive check.

[orveth]

Open-pool sellers on dev aren't deaf-on-CLOSED — they were never subscribed

Found while porting the Loud-Closed fallback for #171. The premise that the degrade protects an open-pool subscription doesn't hold on dev: there is no open-pool subscription to degrade.

1. The open-pool filter was dropped in the cutover

origin/main, seller_daemon/offer_subscription_filters (mod.rs:3148-3182) — targeted filter always, plus an un-pinned open-pool filter when claim_open_pool is set:

let mut filters = vec![Filter::new()
    .kind(Kind::Custom(JOB_OFFER_KIND))
    .hashtag(gateway::MOBEE_TAG)
    .pubkey(seller_pubkey)];

if claim_open_pool {
    // un-pinned, windowed by offer_backfill_secs
    filters.push(untargeted);
}

dev, seller_node/run.rs::subscribe_all — targeted only, unconditionally:

let offer_filter = apply(
    Filter::new()
        .kind(Kind::Custom(JOB_OFFER_KIND))
        .pubkey(self.seller_pubkey),
);

claim_open_pool survives on dev only in the classify path (run.rs:286, via rate_gate_allows) and in tests. So a claim_open_pool = true seller runs a claim gate over offers its subscription can never deliver. The untargeted_needs_open_pool_opt_in tooth passes over a code path production cannot reach. offer_backfill_secs — still a documented, defaulted config knob (home.rs:135-147, default 1200) — is likewise ignored entirely.

Not caught earlier because every node exercised so far ran claim_open_pool = false: the #169 smoke, the devsoak stack, and the wedged specimen are all targeted-only, and targeted claiming works fine.

2. The #t=mobee namespace guard was dropped from the offer filter

Main's targeted offer filter carries .hashtag(MOBEE_TAG) with an explicit note that it's required "so a foreign event squatting the offer kind is never even delivered." On dev the award filter kept the guard (run.rs:411); the offer filter didn't.

Consequence for this issue's framing

The Loud-Closed fallback's degrade-to-targeted is a no-op on dev — it drops a filter that isn't there. Restoring the split has to come first, otherwise the ported fallback is dead code guarding a subscription that was never opened.

Both are addressed in the #171 fix, landing with that PR (they live in the same function the CLOSED arm touches, so deferring them would re-open the same lines): the split and the #t guard are restored, with the pure filter builder teethed — the filter set contains the un-pinned filter iff claim_open_pool, both filters carry the namespace guard, offer_backfill_secs = 0 means live-only (since(now) + limit(0)), and a post-stall resubscribe carries the overlap cursor on both. The degrade then ports faithfully on top of a split that exists.

Also relevant to this issue's observability ask: the offer/award/1059/heartbeat subscriptions now use stable per-role subscription ids rather than generated ones, so a relay CLOSED names which leg died instead of an anonymous id. That was a prerequisite for the CLOSED arm to act differently per subscription, and it makes the "log WHICH" part of the reconciler design cheaper when that slice lands.

[orveth]

Handover: the reconciler's exact target, its tooth lever, and why B1 is the only class it can close

This slice inherits the analysis below from #171's probe-coverage work. Recorded in full rather than summarised, because the reasoning is what constrains the design.

The three classes a subscription-liveness check can face

• (A) the relay stops serving this session's REQs at all. A fresh limit(0) REQ gets no EOSE. Closed by seller node: in-process relay reconnect never re-authenticates (NIP-42) — fresh boot always works #171's EOSE probe — this is the only class with field evidence behind it.
• (B1) the SDK deleted a long-lived subscription from its own map, while the relay still serves new REQs. A fresh probe REQ is answered, so seller node: in-process relay reconnect never re-authenticates (NIP-42) — fresh boot always works #171's probe reports alive and stays quiet. This is what the reconciler is for.
• (B2) the relay forgot a subscription that the client still lists. Both bookkeeping views agree and are both wrong. No client-side check can see this — detecting it needs a real round-trip on that specific subscription, which requires observing our own events, which the SDK denies (nostr-sdk 0.44: a single client can never observe its own published events (standing trap) #174). Residual; document, don't chase.

How B1 actually happens — the CLOSED prefix taxonomy

mobee-relay answers an unauthenticated p-gated kind-1059 REQ with CLOSED restricted:. The SDK maps prefixes into two very different outcomes (relay/inner.rs:1012-1034):

prefix	mapping	consequence
auth-required:	MarkAsClosed (:1024)	subscription kept in the map, closed = true → restored by the post-auth resubscribe()
restricted: (:1028), error: (:1021), duplicate:, pow:, blocked:, invalid:, unsupported:	Remove (:1043)	subscription deleted from the map → should_resubscribe returns false for it (the None arm, :373-379) → never restored

And every SDK reconnect resubscribes in post_connection (:750) before auth completes. So a p-gated subscription being terminally removed is the expected outcome of any background reconnect, not an edge case.

The sentence that matters most: auth-required: is recoverable and restricted:/error: are terminal, and nothing in the client's logs distinguishes them — the subscription simply stops existing. That asymmetry is the whole of B1 in miniature, and it is what decides whether an SDK background reconnect heals a leg or loses it permanently.

Reconciler design (composes with the probe, does not replace it)

On each probe tick, diff the intended set {mobee-offers, mobee-awards, mobee-wraps} against the keys of Relay::subscriptions() (relay/mod.rs:238 → HashMap<SubscriptionId, Vec<Filter>>). Any missing leg → loud log naming which one → re-subscribe it.

Division of labour: the EOSE probe proves the session serves; the diff proves the subscriptions exist. Together they cover (A) and (B1). Neither can reach (B2).

Note this is only possible because #171 gave the subscriptions stable per-role ids (mobee-offers / mobee-awards / mobee-wraps / mobee-liveness-probe) instead of generated ones. With generated ids there is nothing to diff against, and a CLOSED cannot even name which leg died. That was a prerequisite, and it has already landed.

Also worth logging on a successful heal, per this issue's original ask — a silent repair is indistinguishable from nothing having been wrong.

Tooth lever — use QueryPolicy, NOT the NIP-42 path

This one is a trap, and I walked into it before catching it:

• Wrong door: the auth-enforcing fixture (RelayBuilderNip42Mode). Its send_auth_and_close emits auth-required: → MarkAsClosed → subscription kept and restored. That is the benign case. A tooth built on it goes green over a mechanism that never fires.
• Right door: a QueryPolicy returning PolicyResult::Reject(msg). The fixture then sends CLOSED with a hardcoded error: prefix (nostr-relay-builder local/inner.rs:861-872), which the SDK maps to Remove → a real deletion, deterministically manufactured. In-tree precedent for the pattern: job_lifecycle.rs:3098 (CountMetadataQueries).

Shape: fixture rejects the payment-wrap filter → the 1059 subscription is removed from the map → the reconciler's diff notices the leg is gone, logs which, re-subscribes → assert it is back in Relay::subscriptions(). Red-on-revert on the diff. The tooth's subject is our reconciler, not the SDK's prefix mapping.

Why the field's two candidate stalls do NOT justify this slice

Worth recording so nobody cites them as the motivation and then finds the evidence doesn't hold.

The two old-binary codex episodes (7/24-25) look (B)-shaped — offers and awards arriving, trades completing, while the detector saw no round-trip — but B1 is refuted for them, by one fact: on the old binary a terminally-removed subscription can never come back.

1. Terminal CLOSED → Remove → deleted from the map (:1021, :1028, :1043).
2. should_resubscribe returns false for a subscription not in the map (:373-379), so no SDK reconnect can restore it.
3. The manual unsubscribe_all + resubscribe path — the only thing that could re-add it — never completed on old: identical receiver-ordering bug to seller node: in-process relay reconnect never re-authenticates (NIP-42) — fresh boot always works #171 (seller_daemon/mod.rs:3294 receiver, :3298 disconnect), and its success line appears zero times in old-fleet logs.

Terminal removal on old is therefore permanent for the life of the process. Those episodes healed — the echo returned after ~22 minutes. So nothing was ever removed.

What did happen: kind 30340 is addressable/replaceable, so the relay keeps only the newest event per (kind, pubkey, d) and by NIP-01 ignores an older incoming one — ignored meaning not stored and not broadcast. Anything stamping that address into the future (an NTP correction; a second process publishing under the same key and d) silently suppresses every later heartbeat from that seat while leaving other subscriptions untouched, and heals exactly when wall-clock passes the stored stamp. A fixed-duration outage that resolves with no reconnect is a clock offset's signature, not a dead subscription.

So those were transient own-echo artifacts, and the dataset contains zero confirmed genuine subscription stalls. This slice stands on the mechanism being real and code-cited — the Restricted → Remove path is unambiguous — not on field episodes. Don't let anyone attach the episodes to it.

Corollary for future probe authors

Never build round-trip liveness on an addressable/replaceable kind: that is precisely the class of event a relay may legitimately decline to re-broadcast. The old own-echo probe was wrong twice over — accidentally satisfiable (#174) and inherently flaky even when satisfiable.

[orveth]

Correction: the reconciler's footing is weaker than my handover implied

My earlier comment leaned on two field episodes as the shape the reconciler would catch. It should not, and the record should say so plainly.

The classification is now closed, and it went the other way: those two episodes had no reconnect, no re-authentication and no resubscribe at either recovery boundary — the echo returned on a socket that was never disturbed. That excludes both of the classes a reconciler addresses:

• terminal removal (restricted:/error: → Remove) is permanent for the life of the process — should_resubscribe refuses a subscription that is no longer in the map, and that binary's manual resubscribe path never completed. A removed subscription cannot come back, and this one did.
• recoverable close (auth-required:/rate-limited: → MarkAsClosed) heals only via resubscribe(), which runs on connect/auth. No connection event, so no restore.

What actually happened was relay-side replaceable-broadcast suppression on the (kind, pubkey, d) heartbeat address, with everything else on the socket flowing normally — recorded with its evidence in #174.

So: across all of this investigation's data there are zero confirmed genuine subscription deaths. Every observed "stall", on either binary, was a false positive of a probe built on a broadcast.

What that does and does not do to this slice

It removes the field justification. Nobody should cite those episodes for this work; they are not instances of B1 or B1b.

It does not remove the mechanism. B1 and B1b remain real and code-cited, they are simply unobserved:

• B1 — Restricted → HandleClosedMsg::Remove deletes the subscription from the map (relay/inner.rs:1028, :1043), and should_resubscribe then refuses it (:373-379). Since every SDK reconnect resubscribes in post_connection (:750) before auth completes, a p-gated subscription being terminally removed is the expected outcome of a background reconnect, not an edge case. Unobserved, structurally certain.
• B1b — auth-required: and rate-limited: map to MarkAsClosed (:1024, :1016-1019), which keeps the entry and sets closed = true. That flag is exposed by no public accessor: subscriptions() returns HashMap<SubscriptionId, Vec<Filter>> filtered only on is_auto_closing (relay/inner.rs:293-299), and subscription(&id) returns filters alone. So a key-diff reconciler cannot see B1b either — and it does not self-heal, because resubscribe() only runs on connect/auth, so on a stable socket a closed subscription stays dead indefinitely. On a shared relay rate-limited: is the likelier of the two triggers, which makes this the more probable real-world path of the pair.

So this slice now stands on source, not on incidents. Stated as such: it prevents a failure we can prove is reachable but have never caught happening. That is a legitimate footing — it is simply a weaker one than "we saw it", and the difference should be visible to whoever prioritises it.

Design consequence, and it is a simplification

Because B1b is invisible to a key-diff, a reconciler built purely on comparing ids covers only half the mechanism. The cheaper and more complete lever is already public:

Relay::resubscribe() (relay/mod.rs:504) is documented as re-subscribing all closed or not-yet-initiated subscriptions. Calling it on the probe tick restores MarkAsClosed legs without waiting for a reconnect — closing B1b with one call and no bookkeeping of our own. Pair it with the key-diff, which is still needed for B1 (a removed subscription is not "closed", it is absent, so resubscribe() alone will not bring it back):

• resubscribe() on the tick → covers B1b (closed-but-present)
• id diff vs subscriptions() → covers B1 (absent entirely)
• log on successful heal, not only on failure — a silent repair is indistinguishable from nothing having been wrong, which is this issue's original ask

(B2) — the relay forgot a subscription the client still lists — remains closed to any client-side scheme, for the same reason the replaceable-suppression case is: absence of an expected broadcast is unprovable without an independent oracle. Document it; do not chase it. Rooted in #174.

The tooth lever from my earlier comment is unchanged and still correct: manufacture the removal with a QueryPolicy returning PolicyResult::Reject (→ error: → Remove), not via the NIP-42 path (→ auth-required: → MarkAsClosed, the benign case that restores itself and would green a tooth over a mechanism that never fired).

[orveth]

Line item for this slice: wire a tracing subscriber

Recording this here because it's where the observability work will look, and because tonight's investigation paid for it.

mobee installs no tracing subscriber. Not in mobee, not in mobee-core — tracing isn't even a declared dependency of either. So every record nostr-sdk emits goes nowhere:

• "Authenticated to relay" (relay/inner.rs, on each successful NIP-42)
• reconnect / connection-task lifecycle
• "Removing subscription." — the debug-level line emitted on exactly the HandleClosedMsg::Remove path (relay/inner.rs:1046), i.e. the B1 subscription death this slice exists to catch
• "Impossible to resubscribe." / "Impossible to subscribe." on resubscribe failure

That third one is the sharpest loss: the SDK already tells us when it deletes one of our subscriptions, and we throw the message away. A reconciler is the right belt regardless — it detects the state, not just the event, and it also covers a removal that happens before a subscriber is installed — but a subscriber would give the same failure a timestamped line naming the subscription id, for the price of a dependency.

It also cost real diagnostic time: establishing whether a seat's ~22-minute echo outage healed via a reconnect had to be inferred from episode duration, because there was no way to read whether a reconnect had occurred. That inference was one step longer than it needed to be, and I had to explicitly weaken a conclusion built on log silence for exactly this reason.

Suggested shape, kept small:

• tracing-subscriber with an EnvFilter, default warn for nostr_relay_pool (so "Removing subscription." needs opting in at debug), initialised once in mobee's entry point
• writes to stderr alongside the existing eprintln! operator log, so nothing about the current log format changes
• one env knob (RUST_LOG or a MOBEE_LOG alias) so a field seat can be raised to debug without a rebuild — which matters, because the release-debug profile added in seller-node cutover: mobee sell boots the durable seller node #169 already exists for the case where diagnosis needs a rebuild, and this avoids needing one at all

Cheap, and it turns three of this slice's failure modes from "inferred" into "logged".

[orveth]

Correction: this class IS field-observed. My "weaker footing" caveat was wrong.

Two comments up I wrote that the reconciler's justification rests on B1/B1b being "real-but-unobserved" and said the footing was weaker than "we saw it". That was wrong, and the evidence was in the repo the whole time.

origin/main's own source comment, seller_daemon/mod.rs:74-81, explaining why the in-memory daemon carried a periodic payment-wrap backfill:

Cadence (seconds) of the periodic seller wrap backfill. A running daemon re-runs the SAME stored-wrap backfill the boot path uses every this-many seconds, so an AGED relay subscription that has silently stopped delivering kind-1059 payment gift-wraps still recovers WITHOUT a restart. Field-observed: fresh subscriptions deliver a wrap within ~1 min, but a subscription ~10+ min old was seen to go deaf and never deliver again — a payment then sat unredeemed until the daemon was manually restarted (which re-ran the boot backfill).

That is a live subscription going silently deaf on the payment leg, observed, with a real consequence: a stranded payment and a manual restart to recover it. The class this slice addresses has happened, and it cost money.

So the footing is stronger than I stated, not weaker. What I got right is that tonight's two stall episodes are not instances of it — those were replaceable-broadcast suppression (#174). What I got wrong was concluding from that narrow dataset that the class had never been seen. It had; the evidence just lives in a code comment rather than a log.

Why this doesn't make the reconciler redundant

The recovery main relied on — and which I have now restored to the node as a 300s periodic re-fetch (0fece647 on #169) — is response-based: re-ask the relay for stored wraps and ingest what comes back. It recovers the payment without knowing why the subscription went quiet.

That is a different job from this slice's. The backfill restores lost value; a reconciler restores lost registration. Concretely:

• the backfill only covers kind-1059. A silently-dropped offer or award subscription has no equivalent re-fetch, so the seat simply stops seeing work with nothing to repair it.
• the backfill is a workaround, not a diagnosis: it never tells an operator that a subscription died, so a seat can run indefinitely on backfill alone and look healthy while its live subscriptions are dead. Which is exactly the "silent" part of the failure.
• and it can't see B1b at all — a MarkAsClosed subscription is closed, not absent, and no amount of re-fetching wraps re-registers it.

So the three layers stay distinct, and this slice is the one that makes the failure visible:

layer	property	catches
EOSE probe (#171, shipped)	the session answers our REQs	(A) relay stops serving this session
periodic wrap backfill (#169 0fece647)	the money leg recovers value	a deaf 1059 subscription, without a restart — field-observed
this slice	the subscription map is intact	B1 (removed) + B1b (closed-but-present) — and names which leg died

The earlier design notes stand unchanged: Relay::resubscribe() on the tick for B1b, id-diff against Relay::subscriptions() for B1, log on successful heal, and the QueryPolicy-not-NIP-42 tooth lever. The tracing-subscriber item stands too — the SDK already emits "Removing subscription." on the exact Remove path and we discard it.

One thing this reframes: prioritise offers and awards, not 1059. The payment leg now has a safety net; the work legs have none.

[orveth]

Control-arm record for the open-pool story (old-binary fleet, cumulative): across the day, three old-binary seats with claim_open_pool=true evaluated 17/19/19 distinct foreign-targeted offers through their open-pool filters on the current relay build, zero CLOSED frames, zero stalls. Tightest slice: one seat's freshly-issued REQ under the new access-scoping rules served continuously for 5h17m — six distinct foreign-targeted offers (spanning both acceptance smokes) all delivered via the broad filter.

Conclusion held continuously, not just at the split-experiment instant: the relay serves the broad filter fine and keeps serving it; dev's open-pool deafness was entirely client-side (the dropped subscription, restored with teeth in the #169 fix deltas). Relay policy was never the cause.

[orveth]

Operator-surface note from the buyer-watcher work (PR #181), for this slice to inherit: a CLOSED auth-required: log line is ambiguous to a human reader — the retryable-vs-terminal prefix taxonomy (auth-required:/rate-limited: ⇒ MarkAsClosed, kept and re-asserted post-auth; error:/restricted: ⇒ Removed permanently, never restored) decides whether the subscription recovers, but the log message reads identically either way. An operator cannot tell recovery from permanent deafness from the line alone.

When this slice builds the CLOSED arm / reconciler, the log line should state the disposition explicitly — e.g. "CLOSED (retryable — will re-assert after auth)" vs "CLOSED (terminal — subscription removed; re-subscribing)". The buyer side now pins the retryable case with a test (SDK re-asserts + replays work published during the outage, proven on an enforcing fixture); the distinction should be legible in logs, not just in tests.