fix(web): show server update progress through reconnect

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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

[t3dotgg]

The server update action currently becomes a blind pending request, while the expected restart can surface as a generic connection failure. Users cannot tell whether T3 is downloading, installing, or trying to reconnect.

This adds a typed progress stream and one environment-scoped update state machine that follows the operation through Download, Install, and Resume. Resume completes only after the replacement server reports the requested version and is ready for commands. Older servers retain the unary update fallback, and the intentional reconnect gets a fresh retry instead of inherited backoff.

The shared progress rail appears in both the chat warning and Connections. Failed stages remain visible with a retry action. The desktop surface inherits the web implementation; mobile has no existing server-update entry point.

Visual direction: https://f2ltacrf9xro.postplan.dev

Testing:

• contracts, client-runtime, and server typechecks
• focused authorization, self-update, environment, reconnect, update-state, version-skew, and UI tests
• targeted lint and formatting
• web typecheck is currently blocked on current main by unrelated FilePreviewPanel errors against @pierre/diffs/react; the focused web tests pass

Authored by GPT-5.6 Codex in the T3 Code Codex harness.

---

Note

Medium Risk
Touches orchestration RPC auth, self-update handoff timing, and connection supervisor retry semantics; boot-service deferred restart changes when failures are visible vs RPC success.

Overview
Adds Download → Install → Resume visibility for server self-updates instead of a blind pending button, with one shared per-environment state machine in client-runtime so chat and Connections stay in sync across navigation.

Server & contracts: New streaming RPC serverUpdateServerWithProgress emits downloading / installing and a terminal complete; capability serverSelfUpdateProgress is advertised when supported. Unary serverUpdateServer remains for older servers. Self-update accepts optional reportProgress; boot-service handoff defers systemd restart after acknowledgement (like respawn), restores the previous unit on failed restart, and logs instead of failing the RPC when restart cannot complete.

Client-runtime:updateServer drives streamed or legacy unary paths, treats transport loss after handoff as success when appropriate, enters Resume until lifecycle ready at the target version, triggers one fresh reconnect (supervisor retryNow resets backoff), and clears or surfaces failed stage state for retry.

Web UI:ServerUpdateProgress step rail in ChatView and Connections; version-mismatch banner merges with live update state; ServerUpdateAction delegates lifecycle to shared atoms and drops local spinner/timeouts.

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

Note

Show server update progress through reconnect in conversation and connections views

• Adds a new serverUpdateServerWithProgress WebSocket RPC that streams downloading, installing, and resuming progress stages before acknowledging restart; older servers fall back to the existing unary RPC.
• Introduces ServerUpdateState atoms in packages/client-runtime/src/state/server.ts to track update lifecycle (idle/running/failed) with stage, fromVersion, and targetVersion across the client.
• Renders a three-step progress rail (Download → Install → Resume) in ChatView and ConnectionsSettings; suppresses environment-unavailable banners during the resuming stage.
• The update command serializes only its handoff on the config scheduler lane, resets supervisor backoff via retryNow, and waits up to 120 seconds for the server to report the target version as ready.
• For the boot-service path, the server acknowledges immediately and defers the systemd restart; if the restart fails it restores the previous unit file and reloads systemd without surfacing the error to the caller.
• Behavioral Change: resolveServerConfigValue no longer always prefers the live projection — it holds the session config until the live snapshot's serverVersion matches the current server version.

^{Macroscope summarized 16c2f25.}

[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: 889648f8-58c3-448c-9dbd-cc10df48905c

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

---

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.}

One convention finding: the new streaming self-update handler recovers a known tagged failure with Effect.catchTag. Everything else in the changed Effect service scope (service definition/make/layer shape in apps/server/src/cloud/selfUpdate.ts, the new Schema.TaggedErrorClass errors and exported Schema.is predicate in packages/client-runtime, dependency acquisition via yield* EnvironmentRegistry) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

Approvability

Verdict: Needs human review

This PR introduces new streaming RPC infrastructure, new UI progress tracking, and changes server restart behavior from immediate to delayed with rollback. Despite the 'fix' prefix, this is a new feature with significant runtime behavior changes across auth, server, and client that warrants human review.

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

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