fix(web): stop mistaking offline servers for updates

[tris203]

An offline server with a cached version mismatch could display “Finishing an update” despite no update being started.

Remove that inference and reuse the existing reconnecting/offline banner. Known running updates retain their progress banner. After refreshing during an update, the client now shows connection status until the server returns because its in-memory update state is lost.

Validation: focused ChatView logic tests, web typecheck, targeted lint and formatting. Screenshots omitted by maintainer agreement because this reuses existing status presentation.

Implemented with GPT-6 in Codex.

Summary by CodeRabbit

• Bug Fixes
  • Reconnecting environments with version mismatches now use the standard unavailable status instead of a specialized connecting or reconnecting update message.
  • Unavailable status messaging is suppressed while an update is in progress and during the reconnect-warning grace period.
  • Version-mismatch update notifications remain visible when applicable.

[macroscopeapp]

Approvability

Verdict: Approved at a09004d

Macroscope's review found this PR approvable — This single-file correction changes only how reconnecting and cached version-mismatch states are presented: offline servers are no longer shown as finishing an update, while known update progress remains unchanged. It introduces no schema, deployment, product-default, or static-analysis changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 45962762-d7fb-479f-92c7-f5cd85ef9159

📥 Commits

Reviewing files that changed from the base of the PR and between a09004d and 0606679.

📒 Files selected for processing (1)

• apps/web/src/components/ChatView.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

---

📝 Walkthrough

Walkthrough

systemComposerBannerItems now uses the standard unavailable banner for version-skew reconnects. The banner remains suppressed while an update runs or during the reconnect-warning grace period. The version-mismatch update banner is no longer suppressed during version-skew reconnects.

Changes

Reconnect banner handling

Layer / File(s)	Summary
Standard reconnect banner path apps/web/src/components/ChatView.tsx	Removed the special version-skew reconnect progress banner and its update-notice suppression. Reconnecting environments now use the standard unavailable banner logic.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: t3dotgg

Merge Risk: ⚪ Minimal · up to 06066

No established issue currently blocks merging this banner change.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 06066

The change primarily corrects connection-status messaging. It also makes the existing Update action available in a reconnecting state where it was previously hidden. Existing authorization and update guards limit the risk, but update behavior after a refresh is not fully established.

Retained concerns

• Low · reliability · inferred: A cached version mismatch can now present Update during reconnect even when the client has lost its in-memory update state. Existing guards reject an update already in flight on the running server, but cross-refresh and post-handoff repetition are not fully established.

Security review details

Security Blast Radius

• inferred — The newly reachable action is limited to the existing environment-targeted update flow; the inspected change does not increase RPC privilege or establish a new cross-service entrypoint.

Trust Boundaries and Controls

• observed — The banner does not authorize updates itself. The existing RPC enforces operate-scope authorization, while the server update owner rejects an update already in flight in the running service.

Resilience and Maintainability Implications

• inferred — Same-tab pending protection and server-side in-flight protection limit repetition, but the inspected evidence does not settle duplicate initiation after a refresh or server handoff.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main fix: offline servers are no longer mistaken for updates. It is concise and specific.
Description check	✅ Passed	The description explains what changed, why it changed, the UI presentation decision, and validation performed. It does not use the template headings or checklist, but it covers the required informatio…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

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