{"version":"2.1.234","anchor":"remote-control-reconnection-is-driven-by-ownership-not-epoch","canonical_anchor":"remote-control-reconnection-is-driven-by-ownership-not-epoch","heading":"Remote Control reconnection is driven by ownership, not epochs","tier":"internal","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234\/e\/remote-control-reconnection-is-driven-by-ownership-not-epoch","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.234","markdown":"### Remote Control reconnection is driven by ownership, not epochs\n\nRemote Control reconnects based on who owns the session rather than counting registration epochs.\n\n**What**\n\nRemote Control no longer decides reconnection correctness by comparing registration epochs with a retry budget. It now watches for the session owner changing and re-checks ownership before proceeding.\n\n**Details**\n\n- Removed: the compare-and-set epoch fence, the worker epoch tracker, the 4090 `epoch_stale` conflict handler with its per-hour re-registration budget, and the messages about a registration going stale or another connection taking over during restore.\n- Added: an owner-change subscription, plus an owner-changed check before connect, before handling incoming data, and on token refresh.\n- Inbound frames are buffered while an owner check is in flight and drained afterwards; the drain is abandoned if the connection was superseded in the meantime.\n- The owner-change path only runs when the owner check reports it applies.\n\n**Evidence**\n\n`owner_changed_recovery`\n\n- Area: Remote Control\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}