export: banked intelligence for the next Alexa subscription-staleness recurrence — matter.js report-routing defect (HAMH patch) + session-hygiene playbook

[simons-plugins]

Context

Recorded intelligence from the 2026-08-22 investigation of HAMH (riddix/home-assistant-matter-hub), banked as the standing playbook for the next recurrence of production Alexa subscription staleness (#143's unexplained residue: fresh pairings that enumerate then never send a single SubscribeRequest, and healthy subscriptions that collapse). Production is currently healthy (fabric 14, three clean bridge restarts on 2026-08-22), so nothing here should be built until the symptom reproduces.

Finding 1 — a real matter.js 0.17.x defect: subscription reports routed to the peer's newest session

HAMH carries a pnpm patch (patches/@matter__node@0.17.9.patch) to ServerSubscription#sendUpdateMessage. In stock matter.js, routine subscription sends (attribute updates and keepalives) arrive with session === undefined and are resolved via initiateExchange(peerAddress) → SessionManager.maybeSessionFor(), which picks the peer session with the newest activeTimestamp — not the session that holds the subscription. When a controller piles up CASE sessions (HAMH #400 observed 160 on one flapping Echo), a subscription's DataReport can land on a session the controller isn't consuming: it MRP-acks the frame and discards it.

Signature produced: "delivered + ACKed, never rendered" — a second, distinct mechanism for that symptom (independent of the #276 occupancy-event gap; our event fix demonstrably worked through this same send path, so it was not our 08-22 bug).

Their patch pins each send to the subscription's own session, or skips if that session is dead.

Upstream status (checked 2026-08-22): apparently unreported. matter-js/matter.js has an adjacent fix — #4120 "prevent subscription activation on a closing session" (merged 2026-07-20) — but nothing covering update-send routing. Credit for the finding belongs to the HAMH maintainer.

Finding 2 — app-level session hygiene (no matter.js patching required)

HAMH's always-on machinery, all implementable at bridge-node level via public APIs (bridge.ts, session-rotation.ts, wedge-watchdog.ts):

• Dead-session force-close: close sessions with 0 subscriptions that go quiet (their Matter bridges: commissioning a bridge with no bridged children yields no Indigo devices, and the bridged-endpoint path is unverified end to end #105/fix(readopt): sort exported and name-matching devices to the top of the picker (#247) #266; 60s, or 5s in "fast recovery" mode)
• Superseded-session sweep: when a peer establishes a new CASE session, close its stale older ones (their #400 — targets the pile-up precondition of Finding 1)
• Age-based CASE rotation: rotate sessions at 4h
• Wedge watchdog: rotate sessions whose controller keeps MRP-acking pushed reports while sending no inbound IM requests — their comment: "An Apple controller can keep MRP-acking pushed reports … while it has stopped consuming data" (independent corroboration that ACKed ≠ consumed)

Diagnostic to run first when staleness recurs

Count live CASE sessions per Echo peer (41869fbd537ef01 / 41869fd51d8b011) in the bridge log. Multiple piled sessions for a peer with a stale subscription → Finding 1 is in play; the superseded-session sweep is the minimal remedy and the upstream routing fix is the real one.

Explicitly NOT worth adopting (assessed)

• Auto Force Sync: opt-in, 90s, diff-filtered re-push of missed HA→bridge updates only — it cannot refresh what a controller ignores, and their FAQ oversells it.
• matter.js dependency patching: against this repo's stock-npm policy (hand-patch saga, 2026-08-20). The routing fix should arrive via an upstream matter.js release; consider filing it upstream (crediting HAMH's patch) rather than vendoring.

Also confirmed in passing

Alexa's event-vs-attribute consumption is per-cluster: it consumes attribute-only reports for measurement clusters (HAMH #400, temperature), events for occupancy (#276 here) and BooleanState sensors.

[simons-plugins]

Recurrence #1 — 2026-08-23, one day after filing. Diagnostic confirmed, first-aid confirmed.

After last night's Alexa fabric removal and re-pair (fabric 15), the churn cycle appeared within hours:

• 24 SubscribeRequests on the fabric in one day
• Repeating ~30 min cycle: subscribe → Subscription reported invalid by peer → deleted → re-subscribe on a newer session (subs 8ac8f8a8/a9/aa/ab/ac across sessions 8e4f → 8e50 → 8e51)
• The prescribed diagnostic hit: 3 CASE session generations for Echo A (41869fbd537ef01) inside 30 minutes — the piled-sessions precondition for the report-routing defect (Finding 1)
• User-visible: devices intermittently "unresponsive" in the Alexa app between cycles
• Leak-detector poisoning ruled out first (no WaterLeakDetector endpoints in the export)

First aid verified: bridge restart at 16:49 — Apple + Echo A's two subscriptions re-established within 15 s on fresh single sessions, app responsive again (user-confirmed). Restart collapses the session pile, which is consistent with the mechanism: with one session per peer, newest-session routing is trivially correct.

So the trigger pattern is: fabric removal/re-pair → Echo session pile-up → routing defect bites. Yesterday's long-lived fabric 14 ran clean for a full day; the fresh fabric churned within hours. The superseded-session sweep (Finding 2) remains the app-level remedy candidate; this recurrence provides the reproduction environment to verify it against.

[simons-plugins]

Gate override (Simon, 2026-08-24): building the Finding 2 session-hygiene machinery proactively rather than waiting for a recurrence — the #281/#293 work put this bridge under daily controller churn, and the machinery targets Finding 1's pile-up precondition directly. Finding 1 itself (the matter.js report-routing defect) stays an upstream matter; filing it there remains a separate task.