Matter: a standalone node's subscription reports stop being delivered, while commands still work

Traced down from a plugin report (homebridge-plugins/homebridge-ecovacs#309), reported and diagnosed by @valatalo. The plugin registers a robotic vacuum through api.matter.registerPlatformAccessories; Homebridge publishes it as a standalone node, since RoboticVacuumCleaner is in EXTERNAL_DEVICE_TYPES. Everything below is in the Matter layer rather than the plugin.

Symptom

The accessory's tile in Apple Home shows "Updating..." for roughly two minutes on every reopen of the app, even when the device has been in a steady state for a long time and nothing has changed.

The decisive observations

1. Commands work instantly while the tile is stuck. Tapping start/stop drives the vacuum with no delay, at the same moment state reports are not arriving. The path from controller to node is fine; the path from node to controller is not.

2. Pressing Identify unsticks the tile immediately. The log for that moment:

[Matter/MessageExchange] New exchange « @1:3ab66da9•8741⇵fc6c ... peerSess: 8741
[Matter/InteractionServer] Invoke « ... invokes: 1.identify.identify
[Matter/MessageExchange] New exchange » @1:3ab66da9•8741⇵2d17 ... peerSess: b69c
[Matter/MessageChannel] Message » for: I/ReportData sub#: 86d784d0 attr: 1
[Matter/MessageExchange] Message « for: I/StatusResponse

The identify arrives on a peer session (8741) never seen in that subscription's logs, and the pending ReportData for the existing subscription (86d784d0) is delivered only once a further new exchange (b69c) exists.

3. Nothing is ever logged as failing. No Session ended, no error. The node generates reports and records them as sent — including the subscription's own empty keepalive, which asks for an acknowledgement it apparently never gets:

[Matter/MessageChannel] Message » for: I/ReportData sub#: 86d784d0 empty suppressResponse
  backOff: 583ms id: @1:3ab66da9•4c2f⇵ecc0✉038e8466 type: 0x1/0x5 reqAck size: 13

Why this is not a bridge problem

The vacuum is a standalone node with its own id, port, fabric and CASE session. The reporter's parent child bridge holds no other accessories and is not paired at all. So this is not one dead session stranding a shared bridge — it is a node's own session going quiet. The population affected is every standalone Matter accessory, which today means every robot vacuum, across every plugin that publishes one.

Most promising lead: an address the peer has moved off

The reporter noticed the CASE session resolved to three addresses, two IPv6 ULAs and one link-local. iOS rotates its IPv6 privacy addresses periodically. If the node keeps pushing subscription reports to an address the controller has since rotated away from, every symptom follows: sends are recorded as successful, MRP retries reach nothing, anything client-initiated works immediately because the controller opens the connection itself, and the backlog arrives the instant a fresh handshake happens. It also explains why the delay never tracked the plugin's polling interval — the polling was working the whole time, it just had nowhere to go.

Worth checking:

• whether a peer's operational address is ever re-resolved after reports stop being acknowledged, or is cached for the life of the session
• whether a subscription whose reports go unacknowledged is ever torn down so the controller re-subscribes, rather than being pushed into indefinitely
• whether a delivery failure is surfaced at all — at present the node-side log looks identical either way, which is what made this so hard to see

Lesser observation

The reporter also has a second, unnamed fabric (index 2) alongside his named one (index 1), probably left by an earlier pairing attempt. It does not explain the symptom on its own — reports on the live fabric should still arrive — but it is a loose end, and removing a commissioned fabric is not currently possible from the UI (#3979).

Related

#3958 (bridged batPercentRemaining frozen at its pairing-time value in Apple Home) is another "state stops arriving on a Matter accessory" report. Different accessory model, possibly the same delivery problem — worth reading the two together.

Environment

• Homebridge: latest, installed via the Homebridge UI
• Device: Ecovacs Deebot T9, published as a standalone Matter accessory from a child bridge