fix(sync): stop the shell thread list from wedging on a stale cache by DanielGGordon · Pull Request #40 · DanielGGordon/t3code

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DanielGGordon · 2026-07-23T01:01:24Z

The bug

On mobile, the sidebar thread list showed conversations days out of date, and refreshing the page did not help.

The list is not fetched on load. It is a snapshot cached in IndexedDB (t3code:connection-runtime, store shell) that the client renders immediately, skipping the HTTP snapshot entirely, then resumes over a WebSocket using a persisted event cursor. If that resume never completes, the stale cache is what the next load resumes from too — so the wedge is self-reinforcing and survives reloads.

Diagnosed against a live server holding 193 threads with a healthy event log (1→59,935, all projectors current). The data was fine; the client could not get to it.

Three gaps

No retry.subscribeShell passed no retryExpectedFailureAfter, so an expected (non-transport) failure returned a drained stream and the subscription ended for the life of the page. The UI kept rendering the cached snapshot and silently never updated. The thread-detail path already got this right.
Boot-time resume cursor.subscribeInput was computed once, outside the retry/reconnect loop. Every reconnect replayed the same catch-up window rather than resuming from where the client actually got to.
Server always honored afterSequence. Two ways that fails:
- Cursor far behind: every thread-aggregate event in the window costs a getThreadShellById query and emits a full thread shell. On the server that prompted this, a cursor ~6 days old meant ~11k events / ~17MB to rebuild a list a single snapshot expresses in a fraction of that. A client that cannot finish the replay never advances its cursor, so its next attempt is identical — stale indefinitely.
- Cursor ahead of head: a rebuilt/restored event log (or a different server) replays nothing, and every live event is then dropped by the client's sequence <= snapshotSequence check. Stale forever, with no path to recovery.

The fix

Add retryExpectedFailureAfter: "250 millis" to the shell subscription, mirroring the thread path.
Resolve the resume cursor per subscribe. subscribe() now accepts a thunk, so cursor-carrying inputs are re-read on every attempt instead of captured once.
Server falls back to a full snapshot when the client's cursor is ahead of the projected sequence or more than SHELL_CATCH_UP_REPLAY_LIMIT (500) behind. The client applies snapshots wholesale, so this heals a wedged cache. If the server cannot read its own cursor it prefers the previous replay behavior.

Tests

Four new tests, each verified to fail without the corresponding fix (not vacuous):

shell-sync.test.ts — a stream that advances to sequence 9 then fails must resubscribe and ask for afterSequence: 9. Without the retry the recorded attempts are [5]; with the retry but a boot-time cursor they are [5, 5]; fixed, [5, 9].
server.test.ts — replay is still used for a recent cursor (control), and a snapshot is sent when the client is far behind or ahead of head.

packages/client-runtime 255/255 pass; apps/server typechecks clean.

Notes

One pre-existing apps/server test failure (preserves structured workspace rpc failures) and the scripts/test-deploy*.ts typecheck/lint errors are present on the base commit and unrelated to this change — confirmed by stashing.
Not addressed here: static assets ship with no Cache-Control/ETag/Last-Modified (apps/server/src/http.ts), so a phone can also pin a stale JS bundle after a redeploy. The thread-detail cache has the same class of stale-cursor-on-reconnect issue; this PR only makes subscribe() capable of fixing it. Worth follow-ups.
Existing wedged clients still need their site data cleared once; this prevents recurrence and heals clients whose cursor is unusable.

🤖 Generated with Claude Code

The sidebar thread list is a snapshot cached in IndexedDB that resumes over a persisted event cursor. Two gaps let a client pin itself to a stale list that survived reloads, because a reload re-reads the same cache and re-attempts the same resume: - The shell subscription passed no `retryExpectedFailureAfter`, so an expected (non-transport) failure ended the stream for the life of the page. The cached snapshot kept rendering and never updated again. - The resume cursor was captured once at boot, so every reconnect replayed the same catch-up window instead of resuming from where the client actually got to. - The server always honored `afterSequence`. A cursor far behind our head asks for a replay costing far more than the snapshot it stands in for (every thread-aggregate event is a projection lookup plus a full thread shell on the socket), and a client that cannot afford that replay never advances its cursor, so its next attempt is just as expensive. A cursor *ahead* of our head — a rebuilt or restored event log — replayed nothing while every live event was dropped by the client's sequence check. Adds the retry, resolves the resume cursor per subscribe, and falls back to a snapshot when the client's cursor is unusable or too far behind. `subscribe` now accepts a thunk so cursor-carrying inputs are re-read on every attempt. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:L labels Jul 23, 2026

DanielGGordon merged commit 6a4cfdd into mainJul 23, 2026
6 of 10 checks passed

DanielGGordon mentioned this pull request Jul 23, 2026
merge: upstream through 6f34ad3e8 (2026-07-21) — pre-Sidebar-v2 cut #42
Merged