Smooth startup/provider-status warnings and slow request popups

[badcuban]

Priority: P1

User report

When first starting a chat, there is a "runtime warning" that does not explain what it is. It can take about 10 seconds to connect, and the chat window remains blank during that transition.

Follow-up observed on May 26, 2026:

• During an active chat, BadCode showed Codex provider status with Timed out while checking Codex app-server provider status. even though the chat continued to work.
• The global warning toast Some requests are slow / 1 request waiting longer than 15s. appeared during longer-running work.
• The UI did not make it clear whether these were actionable failures, expected long-running provider/status checks, or background requests that should not interrupt the chat flow.

Why

First-run chat startup and in-session provider health warnings are critical trust moments. The UI should make it clear whether BadCode is connecting to the backend, starting a provider runtime, loading a project, waiting on a session, or merely seeing a non-blocking provider-status timeout. Slow-request warnings should be actionable and should not imply the active chat has failed when the provider is still handling turns.

Starting points

• apps/web/src/components/WebSocketConnectionSurface.tsx handles WebSocket reconnect/offline surfaces and shows the Some requests are slow toast from slow RPC ack tracking.
• apps/web/src/rpc/requestLatencyState.ts tracks requests waiting longer than the slow ack threshold.
• apps/web/src/components/ChatView.tsx derives isWorking from phase, isSendBusy, and isConnecting.
• apps/web/src/components/Sidebar.logic.ts has a Connecting thread status state.
• Provider warning display paths include ProviderStatusBanner and provider status helpers.
• apps/server/src/provider/Layers/CodexProvider.ts emits Timed out while checking Codex app-server provider status..
• Server startup/readiness and provider startup events are under apps/server/src/serverRuntimeStartup.ts, apps/server/src/ws.ts, and provider service/runtime layers.

Acceptance criteria

• First chat startup shows a clear non-blank loading/connecting state.
• Runtime warnings include actionable text or link to diagnostics.
• The UI distinguishes backend connection, provider startup, provider-status checks, and thread/session startup.
• A Codex app-server provider-status timeout during an otherwise working chat is shown as stale/degraded status, not as a blocking chat failure.
• Provider-status timeout messaging explains whether chat can continue and gives a clear retry/refresh affordance.
• Long startup waits show progress or a retry/diagnostics affordance.
• Slow-request popups identify the request area/method when possible, or link to diagnostics when details are available.
• Slow-request popups are coalesced/dismissible and do not repeatedly distract during expected long-running chat/provider work.
• Add regression coverage for first-load/first-thread connecting states, provider-status timeout display, and slow-request warning behavior.

[badcuban]

Diagnostics follow-up from May 26, 2026:

I did not find an exact runtime warning string in the recent server trace, but the slow-span data does show provider/status work that can plausibly contribute to first-chat connection delay:

• checkCodexProviderStatus: 6 spans, average about 2.4s, max about 4.8s.
• probeCodexAppServerProvider: 6 spans, average about 1.9s, max about 4.2s.
• checkClaudeProviderStatus: 6 spans, average about 1.6s, max about 2.9s.

When this issue is investigated, include the provider status/probe path in addition to the UI blank-state work.

[badcuban]

Partial progress shipped in 0.0.4: runtime.warning rows now show the warning message/detail inline in the chat work log with warning styling, so reconnect/provider warning rows are no longer opaque. Keeping this open for the remaining startup/provider-status UX and slow-request popup improvements.

[badcuban]

Backlog triage update: this is prioritized for the next practical release because the project direction is now personal local-tool reliability/performance/UX rather than public marketing or hosted web. This should be treated as the top reliability/trust item.

[badcuban]

Partial progress on the P1 startup/provider warning work:

• Provider-status warning/error banners now expose a targeted Refresh action for the current provider and a Diagnostics link.
• The browser local API now forwards targeted server.refreshProviders({ instanceId }) calls instead of dropping the input.
• Slow-request popups now show friendlier area/method labels like Server refresh providers / Source control refresh status, keep the raw method + request id in details, and include a Diagnostics action.
• Added regression coverage for slow RPC labeling/description and targeted provider refresh forwarding. Also added browser coverage for the provider banner actions, but local execution is currently blocked by Playwright's missing chromium_headless_shell-1208 binary; both the repo install script and direct headless-shell install timed out locally.

Verified locally:

• bun fmt
• bun lint (passes with existing warnings)
• bun typecheck
• bun run test src/components/WebSocketConnectionSurface.logic.test.ts src/localApi.test.ts from apps/web

Still open / next priority:

• First chat startup still needs the clear non-blank connecting/startup state.
• The UI still needs a stronger distinction between backend connection, provider startup, provider-status checks, and thread/session startup.
• Long startup waits should get the same retry/diagnostics affordance treatment.

[badcuban]

Additional follow-up in the same pass:

• The chat timeline now treats session.orchestrationStatus === starting as active work, so after the server acknowledges a first turn the thread continues to show a live activity row instead of falling back to an empty/blank conversation area.
• The live label for that phase is now Starting session, which separates server-acknowledged session startup from the earlier local Sending / Connecting state.
• Added regression coverage for the new startup label.

Re-verified:

• bun fmt
• bun lint (passes with existing warnings)
• bun typecheck
• bun run test src/session-logic.test.ts src/components/WebSocketConnectionSurface.logic.test.ts src/localApi.test.ts from apps/web

Still open:

• More granular backend-vs-provider-vs-thread startup language and progress if we want to go past this initial non-blank state.
• Local browser test execution remains blocked by Playwright browser download/install timeouts.

[badcuban]

Closing this out ahead of the public release. All three original reports are addressed, and 8 of 9 acceptance criteria are fully met — the remaining sliver is tracked in #38.

Original reports → current behavior

• Blank window for ~10s on first chat — the timeline now treats server-acknowledged session startup as active work and shows a live "Starting session" activity row with an elapsed timer (session-logic.ts / deriveActiveStatusLabel), with distinct Connecting / Sending / Preparing worktree / Waiting-for-approval states.
• Provider-status timeout presented as a chat failure — provider warnings are suppressed entirely while a turn is in progress; Codex probe pending/timeout render as a compact inline notice (never a blocking alert), probe-pending is quiet for the first 25s, and the timeout message now says whether chat can continue ("Existing sessions may still work; refresh provider status if this keeps happening"). Every banner carries a targeted Refresh (server.refreshProviders({ instanceId })) and a Diagnostics link. Server-side, provider probes moved off the request path: instances start from a persisted status cache and probe asynchronously on a refresh interval, with provider_probe_pending / provider_probe_timeout as first-class status reasons.
• "Some requests are slow" toast — removed by design rather than polished. Slow RPCs are no longer surfaced as popups at all; they're visible in Settings → Diagnostics with friendly area/method labels ("Server refresh providers") plus raw method and request id. If we ever want an ambient indicator back, that's noted in Add a distinct provider-startup phase to session startup states #38.

Landed while closing this out

• Long startup waits now get the same affordance treatment as slow probes: if "Starting session" persists past 30s, a compact notice appears with Refresh + Diagnostics actions (SessionStartupNotice, suppressed when a provider or thread-error banner is already explaining the situation). Logic + browser regression tests included.

Coverage

Regression tests exist for the startup label, banner display rules (including "does not float probe warnings over an active turn"), targeted refresh forwarding, slow-RPC labeling, and the new startup notice. The Playwright install blocker from the earlier comments is resolved — CI installs and runs the browser suite.

Still open (moved to #38)

• A distinct "provider starting" phase: spawning the provider runtime is currently indistinguishable from general session startup because no runtime event exists between turn dispatch and session.started. Needs a contract + server + projection change, so it's deliberately deferred past the release.

One process note: the fixes above are verified at the code level; the clean-machine first-run walkthrough (no providers → codex login → claude login → first chat) is on the release checklist rather than this issue.