Repository navigation
Conversation
…ost is unreachable at startup (cherry picked from commit d41996f)
|
@AmethystLiang three small web-client/orcad fixes from running the orcad-served webapp headless:
Each branch is off current main and self-contained. Refs the template's issue-linking requirement: #2 links #18504; #1 relates to #13201; #3 has no matching issue yet - happy to file one if preferred. |
📝 WalkthroughWalkthroughRecoverable remote-runtime connection errors now use offline startup recovery instead of degraded no-save recovery. This path marks startup refresh complete, forces workspace readiness, and displays a retry toast. It relaunches when the runtime transport becomes ready. A new healing helper probes the serving origin and, after a successful uncancelled response, stores an endpoint override and rebuilds active runtime clients. Valid overrides are used when resolving the preferred pairing endpoint. Priority: ➖ Normal Severity of issue fixed: Medium Merge Risk: 🟡 Moderate · up to Startup recovery now mounts the app offline when it cannot reach the host. Two gaps remain. A busy host whose request queue is full can be treated as unreachable, which can skip the safer degraded mode after partial loading. A different runtime becoming ready can also trigger an early reload. Narrow the offline condition before merging. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Description checkExplanation The description covers the required sections, user-visible behavior, rationale, linked issue, testing, and compatibility considerations. However, it does not provide the required before-and-after visual proof for this UI behavior change, and it leaves required testing checklist items unchecked without explaining the omissions. Resolution Attach before-and-after screenshots or a video showing the previous degraded state and the new offline recovery state. Check the applicable testing items and document why automated tests were not added, or add and report the required lint, typecheck, test, and build verification.
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
- Configuration used: Repository UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
d1b9a04a-6719-4fdb-b9d6-c342dfaaff01
📒 Files selected for processing (1)
src/renderer/src/startup/startup-degraded-recovery.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.
| const unsubscribe = window.api.runtimeEnvironments.onStatusChanged((snapshot) => { | ||
| if (snapshot.transport === 'ready') { | ||
| unsubscribe() | ||
| void window.api.app.relaunch() |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
#!/bin/bash
# Inspect the status snapshot identity and the channel's event producers.
rg -n -C 5 'RuntimeHostStatusSnapshot|RUNTIME_HOST_STATUS_CHANNEL|onStatusChanged\(' srcRepository: stablyai/orca
Length of output: 41725
🏁 Script executed:
set -eu
printf '%s\n' '--- snapshot declaration ---'
rg -n -F -- 'export type RuntimeHostStatusSnapshot' src/shared src/main src/preload src/renderer
sed -n '1,240p' src/shared/runtime-host-status.ts
printf '%s\n' '--- channel and event producers ---'
rg -n -F -- 'RUNTIME_HOST_STATUS_CHANNEL' src/main src/preload src/shared src/renderer
rg -n -F -- 'onStatusChanged' src/main src/preload src/renderer
rg -n -F -- 'publish' src/main src/shared/runtime-host-status.ts | head -80
printf '%s\n' '--- startup recovery and callers ---'
sed -n '1,230p' src/renderer/src/startup/startup-degraded-recovery.ts
rg -n -C 8 -F -- 'recoverFromDegradedStartup' src/renderer src/main src/preloadRepository: stablyai/orca
Length of output: 32218
🏁 Script executed:
set -eu
printf '%s\n' '--- main status owner ---'
sed -n '1,180p' src/main/ipc/runtime-environment-status-owner.ts
rg -n -C 8 -F -- 'RuntimeHostStatusOwner' src/main src/renderer src/preload
printf '%s\n' '--- web runtime status API ---'
sed -n '1,180p' src/renderer/src/web/preload-api/web-runtime-environments-api.ts
rg -n -C 10 -F -- 'subscribeWebRuntimeStatus' src/renderer/src/web src/main src/preload
printf '%s\n' '--- web entrypoints and startup recovery binding ---'
rg -n -C 8 -F -- 'startup-degraded-recovery' src/renderer/src/web src/renderer/src
rg -n -C 8 -F -- 'recoverFromUnreachableStartup' src
rg -n -C 8 -F -- 'web-runtime-environments-api' srcRepository: stablyai/orca
Length of output: 39406
🏁 Script executed:
set -eu
printf '%s\n' '--- status owner implementation ---'
sed -n '1,260p' src/shared/runtime-host-status-owner.ts
printf '%s\n' '--- status owner lifecycle ---'
sed -n '36,150p' src/main/ipc/runtime-environment-request-connections.ts
rg -n -C 6 -F -- 'getRuntimeEnvironmentStatusOwner(' src/main/ipc src/mainRepository: stablyai/orca
Length of output: 29652
Filter ready snapshots by the paired environment.
The Electron status channel delivers snapshots from every runtime status owner. This listener checks only snapshot.transport === 'ready', so another environment becoming ready can relaunch the still-offline app. Pass the paired environment ID into this recovery path and require snapshot.environmentId to match before relaunching.
…artup When the stored WebSocket endpoint is unreachable but the page itself was served by an orcad, probe ws(s)://<origin> with the stored device token and pinned host key — an authenticated status.get is the identity proof. The redirect is kept in a separate endpoint-override store because the server-store merge resurrects stale stored endpoints; mutating endpoints[] gets clobbered back to the dead address. Also classify the code-less 'Timed out while connecting to the remote Orca runtime' waiter error as recoverable so hydration reaches the offline+heal path instead of the no-save degraded lock. (cherry picked from commit 898ee9f)
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to GitHub limitations.
🟠 Major · Restrict offline recovery to connection unavailability. · startup-degraded-recovery.ts:68
src/renderer/src/startup/startup-degraded-recovery.ts:68
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy liftRestrict offline recovery to connection unavailability.
isRecoverableRemoteRuntimeConnectionErroralso acceptsruntime_rpc_queue_overloaded. If startup receives that error after hydration begins, this branch can skip degraded recovery and mark the partially hydrated workspace ready as though the host were unreachable. Keep queue-overload and partial-hydration failures on the existing degraded path.
ℹ️ Review info
⚙️ Run configuration
- Configuration used: Repository UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
79ec8472-e490-4ab6-af97-3baf85442f96
📒 Files selected for processing (5)
src/renderer/src/startup/startup-degraded-recovery.tssrc/renderer/src/startup/startup-unreachable-host-heal.tssrc/renderer/src/web/web-runtime-endpoint-overrides.tssrc/renderer/src/web/web-runtime-environment.tssrc/shared/remote-runtime-client-error-classification.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
ELI5
On the web client, the "local" catalog is the paired host over a WebSocket. If that host is unreachable when the app boots (daemon down, port changed, stale entry), the app locked itself into a "session restore failed / changes won't be saved" mode - even though nothing was actually lost - and the user could not add projects, open terminals, or fix the connection from the UI.
What Changed
recoverFromDegradedStartupnow classifies the thrown error with the existingisRecoverableRemoteRuntimeConnectionErrorclassifier; a recoverable connection error takes a new offline path instead of the no-save path.transport === 'ready'status snapshot - the WS transport already auto-reconnects on its own.Before: unreachable host → hydration chain aborts → "Session restore failed" + no-save lock. After: unreachable host → app mounts offline with a retry toast and self-reloads when the host answers.
Why
An unreachable paired host is not a session fault: nothing half-hydrated, so the no-save lock protects nothing. Mounting offline keeps the UI usable (you can fix the connection) and the
ready-snapshot reload reuses the transport's own reconnection instead of inventing a second retry loop. Genuine corruption still gets the conservative degraded path, so the safety behavior for real faults is untouched.Fixes #26620
Visual Proof
N/A for attachments here; behavioral before/after: before, a dead stored host left the web client behind a "Session restore failed" toast with no way to interact; after, the shell mounts with a "Could not reach the Orca host" toast (Retry now) and reloads itself once the host is back. Can attach captures on request.
Testing
pnpm tc:webclean.AI Disclosure
Authored with an AI coding agent (GLM via Maki); human reviewed and verified the diff.
Review
Agent skill upstream boundary
Notes
Security: no new capability; the reload only triggers on the app's own transport status. Cross-platform: renderer-only, no platform branching. Remote/SSH: this is the paired-host recovery path for web clients. Backwards compatibility: behavior change only for the unreachable-host case previously locked out. Performance: adds one status subscription during offline mode, removed on first ready snapshot or abort.
Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)