fix(client): self-heal empty thread details and back off failed thread subscriptions

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[colonelpanic8]

What Changed

Two client-runtime fixes for thread views that can render empty forever:

• Self-heal empty cached thread bodies.makeEnvironmentThreadState skipped the HTTP snapshot whenever any cached body existed and resumed the socket subscription from the cached snapshot sequence. If the cached body had no messages but a current sequence, the events that carried the messages were below the resume cursor and were never replayed — the thread rendered empty permanently, surviving app restarts. The subscription now reloads the HTTP snapshot whenever the cached body has no messages, and still degrades to today's sequence-resume when the loader yields nothing (offline/404).
• Exponential backoff for expected subscription failures.subscribeDynamic's retryExpectedFailureAfter now also accepts (attempt: number) => Duration.Input, with the consecutive-failure counter reset by any delivered element. The thread subscription uses it: 250ms base, doubling, capped at 2s while the thread has no data and 10s once data exists. Existing plain-duration call sites are unchanged.

Why

An unsent composer draft subscribes to its pre-allocated thread id before the thread exists server-side (intentionally, so the subscription picks the thread up the moment the draft is submitted). With the flat 250ms retry, every open draft hot-looped an HTTP snapshot fetch + socket subscribe into a 404 four times per second, indefinitely. Measured before: steady ~4 req/s for as long as a draft stays open. Measured after: 250ms → 500ms → 1s → 2s steady (≤2s worst-case pickup after the draft is submitted; verified live that draft submission still promotes promptly and the created thread's messages appear).

The 2s/10s split matters because the draft-promotion flow renders the message timeline from the thread-detail subscription: a thread with no data yet may be created at any moment and must be picked up quickly, while a thread that already has data and keeps failing can back way off.

The empty-cache self-heal closes the loop for users who already have a poisoned cache: previously nothing ever re-fetched the full body, so the thread stayed empty forever.

Checklist

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

Validation:

vp check # 0 errors
vp run typecheck # exit 0
vp test run packages/client-runtime/src/state/threads-sync.test.ts packages/client-runtime/src/rpc/client.test.ts # 28 passed

Plus a live pass in an isolated vp run dev environment: draft-open retry cadence measured at 250ms/500ms/1s/2s-steady (previously flat 250ms), draft submission still promotes and shows its messages, and existing threads render normally across reloads.

---

Note

Medium Risk
Changes thread sync and retry behavior for all thread detail subscriptions; wrong backoff or snapshot logic could delay live updates or add extra HTTP load, but scope is client-runtime only with broad test coverage.

Overview
Fixes thread views that could stay empty forever and stops draft subscriptions from hot-looping on 404s.

Empty cached thread bodies now trigger an HTTP snapshot reload before the live subscription resumes when the cached body has no messages, so replay does not skip message events below the cached sequence. If the loader returns nothing (offline/404), behavior falls back to resuming from the cached sequence as before.

Expected subscription failures use exponential backoff instead of a flat delay: retryExpectedFailureAfter accepts a duration or (attempt) => duration, consecutive failures increase the wait, and any delivered stream element resets the counter. Thread subscriptions use 250ms base doubling, capped at 2s without message data (draft / not-yet-created threads) and 10s once data exists.

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

Note

Fix thread subscriptions to self-heal empty thread details and back off on repeated failures

• When a cached thread has no messages, the client now reloads the HTTP snapshot before resuming the live subscription, falling back to the cached sequence if the reload yields nothing (e.g. offline/404).
• Replaces the fixed retryExpectedFailureAfter delay with an exponential backoff via retrySubscribeBackoff in threads.ts: capped at 2s when no data exists, 10s when cached data is present.
• Extends SubscriptionOptions.retryExpectedFailureAfter in client.ts to accept a function (attempt: number) => Duration.Input, enabling per-attempt delay computation.
• Backoff counter resets to zero whenever an element is delivered from the stream.
• Behavioral Change: threads with empty cached message arrays now trigger an extra HTTP snapshot fetch before subscribing to live events.

^{Macroscope summarized e17b96e.}

[coderabbitai]

Important

Review skipped

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

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 75d93c73-b6dd-4ec1-a113-19f612b4dd5b

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[cursor]

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

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

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

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR modifies runtime retry behavior for thread subscriptions, changing from fixed 250ms delays to exponential backoff with different caps based on data state. It also adds self-healing for empty cached threads. These are meaningful behavioral changes to client synchronization that warrant human review.

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

[t3dotgg]

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.

This branch overlaps the subscription repairs in #8192 and #8193. Those focused PRs are the active paths for missing-thread and retry behavior.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.