fix(web): reconcile client state when a settle does not land by colonelpanic8 · Pull Request #4593 · pingdotgg/t3code

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

colonelpanic8 · 2026-07-26T21:51:45Z

What Changed

Settle can now recover a client whose view has drifted from the server, instead of requiring a client restart.

New resync-requestedConnectionWakeup. Snapshot-backed subscriptions (shell, threads) already reconcile on a foreground wake — reload the HTTP snapshot, resume the stream from its sequence — but nothing could ask for that on demand. They now resubscribe on this reason too, via a shared wakeupResubscribes predicate.
New ResyncRequests emitter in client-runtime, merged into the web app's wakeups layer.
settleThread requests a reconcile when it observes a disagreement:
- when the local canSettle guard blocks the send, and
- when a settle the server accepted never lands in the local view (checked at 150/500/1200 ms, then escalated).
Requests are coalesced behind a 5 s window, so bulk settle asks once rather than once per thread.

Why

Settling acts on the client's local view, and when that view is stale the action becomes unrecoverable in both directions:

canSettle (threadSettled.ts) refuses to send while the client's copy of session.status is starting | running, even if the server has since moved the session to ready.
A settle the server accepts against an already-settled thread is a deliberate idempotent no-op — it re-emits thread.settled with the original settledAt and the existing updatedAt (decider.ts) so bulk-settle and double-click stay quiet. If the local view never applies the resulting thread-upserted, every subsequent click succeeds while changing nothing visible.

Either way the control reads as dead and the thread cannot be moved to settled at all. The only known fix was restarting the client — which works precisely because it reloads the snapshot and resubscribes. This makes that same reconciliation reachable in place.

The server side already publishes what a client needs to converge: threadUpsertOrRemove re-reads the current projected row and emits thread-upserted after any thread event, including the idempotent re-emit. The gap is that nothing on the client notices when its view has stopped tracking that.

Reported in #4589.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes — no visual change; this only affects when a reconcile is requested
I included a video for animation/interaction changes — n/a

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

vitest run apps/web/src/lib/ packages/client-runtime/src/state/ # 429 passed
tsgo --noEmit # apps/web, packages/client-runtime — clean
vp lint --report-unused-disable-directives # no findings in changed files

Note on verification honesty: the underlying desync has no deterministic repro yet, so the new escalation path is covered by unit tests rather than an end-to-end reproduction. The happy path is unchanged — the convergence check reads once and exits.

Note

Medium Risk
Touches live subscription reconciliation and thread lifecycle UX; behavior is guarded by throttling and unit tests but the underlying desync has no deterministic E2E repro.

Overview
Fixes settle appearing broken when the local thread view is stale: the server may accept the command (or the client may block on canSettle) while the UI never updates until a restart.

Adds an on-demand resync-requested connection wakeup (via ResyncRequests in client-runtime, merged into the web wakeups layer). Shell and thread snapshot subscriptions now resubscribe on that reason as well as foreground activation, using shared wakeupResubscribes.

settleThread requests a coalesced reconcile (5s trailing-edge throttle in resyncRequests.ts) when the local canSettle guard blocks, and after a successful settle runs confirmSettleConverged polling; if settled state still does not appear, it escalates to another resync.

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

Note

Reconcile client state when a thread settle does not land locally

Adds a resync-requested wakeup type to ConnectionWakeup and wires it into the wakeups layer via a new ResyncRequests.resyncRequestStream in platform.ts.
Adds settleConvergence.ts, which polls the local thread shell after a successful settle and calls requestResync if the settled state never converges.
Adds resyncRequests.ts, a trailing-edge coalescing wrapper that fires at most one immediate and one trailing resync per 5-second window.
Updates settleThread in useThreadActions.ts to request a resync when a local canSettle check fails, and to run convergence polling after a successful mutation.
foregroundResubscriptions in shell.ts and threads.ts now resubscribe on resync-requested in addition to application-active.

^{Macroscope summarized 5fc3aef.}

coderabbitai · 2026-07-26T21:51:53Z

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: 7aafa55e-231f-4def-b5dd-92cf8e16bd20

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

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

…s not land)

macroscopeapp · 2026-07-26T21:55:49Z

Approvability

Verdict: Needs human review

This PR introduces new client-side state reconciliation logic including a new wakeup type, throttled resync requests, and convergence polling after settle operations. While well-tested, these changes significantly affect runtime behavior around client/server state synchronization and warrant human review.

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

…s not land)

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 95aa505. Configure here.}

…s not land)

Settling a thread acts on the client's local view. When that view has drifted from the server the action becomes unrecoverable: `canSettle` refuses to send against a stale `running` session, and a settle the server accepts is a deliberate idempotent no-op that changes nothing the client can see. Either way the control looks dead, and the only known fix is restarting the client. Snapshot-backed subscriptions already know how to reconcile — they reload the HTTP snapshot and resume the stream from its sequence on a foreground wake. Nothing could ask for that on demand. Add a `resync-requested` wakeup so the same reconciliation is reachable in place, and have the settle action request it when it observes a disagreement: when the local guard blocks, and when an accepted settle never lands in the local view. The convergence check polls only after an explicit user action and only until the view agrees, so the healthy path costs one read. Requests are coalesced, since one reconcile covers the whole environment and bulk settle would otherwise ask once per thread. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Review found two ways the coalescing window could suppress the very reconcile this change exists to perform. Leading-edge-only coalescing dropped any request arriving within the window. But a request exists because something observed the client disagreeing with the server, so dropping it leaves that disagreement standing until the user happens to act again — a settle blocked by a stale guard, or another thread's earlier resync, could strand a later accepted settle. Suppressed requests now collapse into one reconcile at the end of the window instead of vanishing. A backward clock jump also wedged the throttle shut: a negative elapsed compares as inside the window, so every reconcile was suppressed until wall time caught back up to the old timestamp. Treat it as a fresh window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

An immediate reconcile — an open window, or a backward clock jump — left any pending trailing timer scheduled, so one logical request could produce two reconciles and defeat the coalescing. Track whether a request is still outstanding rather than cancelling the timer. The obsolete timer becomes a no-op, while a request raised after the superseding reconcile still gets its own trailing fire instead of being dropped along with the obsolete one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…does not land)

t3dotgg · 2026-08-27T11:22:46Z

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

Closing the settle-specific polling workaround. It adds another recovery loop and global resync signal around one client action. The underlying subscription failure should be repaired in shared recovery. The related recovery PR is still open, so this closure does not mean the desynchronization bug is already fixed. Related work: #4602.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. If GitHub does not let you reopen it, leave a comment here and we'll take another look.

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Jul 26, 2026

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 26, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
8242a98
…s not land)

macroscopeappBot reviewed Jul 26, 2026
View reviewed changes

Comment threadapps/web/src/lib/resyncRequests.ts Outdated

cursorBot reviewed Jul 26, 2026
View reviewed changes

Comment threadapps/web/src/lib/resyncRequests.ts

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 26, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
df00fc3
…s not land)

cursorBot reviewed Jul 26, 2026
View reviewed changes

Comment threadapps/web/src/lib/resyncRequests.ts

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 26, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
8c2061c
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
5e77f60
…s not land)

colonelpanic8 mentioned this pull request Jul 27, 2026
[Bug]: An environment's threads silently stop updating until the client is restarted #4589
Open
2 tasks

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
2565ec1
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
1d5bcda
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
ad4212b
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
995f555
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
4a074ab
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
9797f31
…s not land)

colonelpanic8 force-pushed the t3code/settle-state-reconcile branch from 6980a8c to 86bcba0Compare July 27, 2026 11:15

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
241a6ad
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
7a4fdb9
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
ce3be72
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
300e859
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
31dbc71
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
e6f3f65
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
a6b1447
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 27, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
c659659
…s not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 28, 2026
stack: mergepingdotgg#4593(Reconcile client state when a settle doe…
83b62ed
…s not land)

colonelpanic8 force-pushed the t3code/settle-state-reconcile branch from 86bcba0 to c4d02afCompare July 28, 2026 02:08

colonelpanic8and others added 3 commits July 27, 2026 19:47

colonelpanic8 force-pushed the t3code/settle-state-reconcile branch from c4d02af to 5fc3aefCompare July 28, 2026 02:51

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 28, 2026
assembly: mergepingdotgg#4593(Reconcile client state when a settle …
cead60e
…does not land)

colonelpanic8 added a commit to colonelpanic8/t3code that referenced this pull request Jul 28, 2026
assembly: mergepingdotgg#4593(Reconcile client state when a settle …
ba862db
…does not land)

t3dotgg closed this Aug 27, 2026