fix(client-runtime): recover subscriptions that lose their transport

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}

[colonelpanic8]

What Changed

A durable subscription that fails with a transport-level RpcClientError now asks the supervisor to re-establish the session, instead of draining and waiting for a session that may never come.

Requests are coalesced per session via a WeakSet keyed on the session object, so a burst of subscription failures produces exactly one reconnect request.

Why

subscribeDynamic handles a transport failure by logging and draining, deferring to "the next session". Nothing guarantees one arrives. supervisor.session is written only when a connection lease is established (connection/supervisor.ts:532) or cleared on teardown (:243), and the only liveness probe runs on an application-active wakeup — a desktop window that stays visible never health-checks its connection.

So a stream that dies while the session stays usable — a half-open socket (NAT idle timeout, sleep/resume, VPN flap, where no close is ever delivered), or a failure confined to that one stream — leaves the subscription dead for the lifetime of the session.

Nothing surfaces it. Unary RPCs on that same session keep working, so the app looks connected and commands still round-trip while the environment's state silently stops updating.

This was diagnosed from a case where client and server were on different machines, so both sides could be inspected independently (#4589). On one connection at one moment:

• ten thread.settle commands were accepted server-side, with receipts
• the pre-existing shell subscription was dead — a new thread created during the incident never appeared in the sidebar, though the server had it running
• a thread-detail subscription created after the failure worked fine

That asymmetry is the signature: the drain is per subscription stream, so subscribeToSession() runs fresh for anything started afterward while already-drained streams stay dead. A connection-level failure could not produce it — it would take out the new subscription too. Other clients against the same server were unaffected throughout.

The user-visible result is an environment frozen in place: threads stuck showing Working long after they finished, new threads missing from the sidebar, and lifecycle actions succeeding as no-ops against a stale view. Only restarting the client recovers it, because a restart is the one thing that makes a new session.

Note that the branch immediately below this one already retries within the same session when retryExpectedFailureAfter is set (state/shell.ts passes "250 millis"). Only the transport branch had no path back.

Why coalesce

An environment carries many durable subscriptions — the shell, the thread list, every open thread — and a dead transport tends to take all of them at the same moment. Each retryNow is a signal the supervisor acts on, and a signal delivered mid-establishment aborts that attempt (supervisor.ts:362-384). N unfiltered requests would abort N reconnects and stall recovery exactly when it is needed. The regression test for this fails with expected 2 to be 1 if the guard is removed.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes — no UI change
• I included a video for animation/interaction changes — n/a

---

One existing test changed its expectation. "keeps durable subscriptions alive across a transport failure and new session" asserted retryCount === 0, and passed only because the test manually supplies the replacement session that production has no way to produce. It now expects one request.

Validation (scoped per AGENTS.md, which reserves repo-wide vp check / vp run typecheck for CI):

vitest run packages/client-runtime/src/ # 473 passed
tsgo --noEmit # packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Not addressed here, both worth their own change: unary request (rpc/client.ts:107) has no timeout, so a call into a hung session never settles — which can latch an in-flight guard in the UI; and there is no periodic liveness probe, only the application-active one.

---

Note

Medium Risk
Changes connection recovery for all durable environment subscriptions; incorrect coalescing or stale-session handling could over- or under-reconnect, but scope is limited to transport failures and is heavily tested.

Overview
Durable RPC subscriptions that fail with a transport-level RpcClientError no longer only log and drain while hoping the supervisor swaps sessions. subscribeDynamic now calls requestSessionRecovery, which triggers supervisor.retryNow when the failing session is still the active one, so reconnect can happen even when the socket looks fine to unary calls.

Recovery is coalesced per session with WeakSet guards so many subscriptions dying together produce one reconnect signal; stale sessions and in-flight duplicates are ignored. Domain failures still do not reconnect.

Tests cover single and multi-subscription reconnect, stale-session filtering, resubscribe interrupting recovery, and the updated expectation that transport failure implies one retryNow.

^{Reviewed by Cursor Bugbot for commit b5836f1. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subscribeDynamic to recover subscriptions that lose their transport

• When an RpcClient subscription fails with a transport error, subscribeDynamic now calls supervisor.retryNow before draining to await the next session.
• A new requestSessionRecovery effect coalesces recovery signals per session: only one retryNow is issued per broken session, and signals from already-replaced sessions are ignored.
• New tests in client.test.ts cover deduplication, stale-session filtering, and in-flight resubscription interleaving.
• Behavioral Change: subscriptions that previously silently drained on transport loss now actively trigger supervisor reconnection.

^{Macroscope summarized b5836f1.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 38f0bf65-d02c-404b-adf3-0c79451f3d23

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b80214c. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces new subscription recovery behavior in the client-runtime connection layer, including module-level state tracking and changes to how subscriptions coordinate with the supervisor during transport failures. While well-tested, these are meaningful changes to connection lifecycle management that warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}