feat: choose updates and restart this device first#23870

🟠 High sidebar/updateEverythingPlan.ts:208

Opening or reloading a second window while the original window is downloading or counting down pauses the healthy app update, forcing a manual Retry. The second window sets recoveringClaims even though the original renderer still owns the claim, so this branch marks the plan paused; the owner then fails its phase check and releases the claim. Confirm the claim owner is actually abandoned before pausing the plan.

No longer relevant as of 278e64c34f17f4f2f0a658f075d0c2efb74e8792

Fixed in 0cc17105686e4a2e8243a1a62b2e0e5af403d1bf. Each renderer holds its own Web Lock before it can claim work. Recovery checks the observed owner, then atomically rechecks the same plan, phase, item and claim before pausing. A live owner is left alone; its exit wakes recovery. Added healthy/dead owner, claim-change and phase-change regressions plus real Web Locks/IndexedDB tests.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟠 High sidebar/updateEverythingMaintenance.ts:42

When the catalog is ready but there are no hostedByThisApp machines, waitForHostedMaintenance rejects with A local connection is not ready, blocking desktop updates in remote-only mode. The hosted.length === 0 rejection and the hosted.length > 0 requirement in isHostedMaintenanceReady both cause this; treat an empty hosted set as ready once the catalog is ready.

No longer relevant as of a2562316fd2dafbd2b0d5f4d718f18cb0b10c8ef

Fixed in 0cc17105686e4a2e8243a1a62b2e0e5af403d1bf. A ready catalog with no hosted machines passes the automatic gate only when the primary is null and the local server is explicitly off. Failed discovery with the local server on still rejects. Added positive and negative maintenance tests.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟡 Medium sidebar/updateEverythingRun.tsx:523

The capsule keeps showing stale progress until the entire runUpdatePlan call finishes, so completed devices remain pending and failures stay hidden while other updates are still running. Store and snapshot notifications only set coordinatorAgain while the coordinator is awaiting execution; refresh showPlan independently of that serialized loop.

No longer relevant as of 278e64c34f17f4f2f0a658f075d0c2efb74e8792

Fixed in 0cc17105686e4a2e8243a1a62b2e0e5af403d1bf. Store notifications now publish committed progress while the runner is still waiting. A shared generation prevents older reads from replacing fresh results. The browser regression shows completed and failed devices while another update is blocked, then releases an old read and checks that progress stays current.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Tell the user when startUpdatePlan starts nothing.

startUpdatePlan returns { status: "empty" } in two cases:

• every selected key disappeared from operations after the dialog opened, for example because a connection dropped or a permission changed
• snapshot.ready is false

In both cases, the dialog closes and nothing happens. The user gets no feedback. The storage-failure path already shows a toast, but the other "empty" causes do not. Show an info or warning toast for "empty", as the code already does for "busy".

✅ Confirmed as addressed by @Bil0000

Fixed in 0cc17105686e4a2e8243a1a62b2e0e5af403d1bf. The stale-selection branch now shows “No selected updates can start right now.” Storage failures keep their separate error toast. The browser regression checks the empty result, user message, and absence of a saved plan.

@Bil0000 Thanks for the fix. The reported change addresses the missing feedback and keeps storage errors separate. The described browser regression covers the empty result, user message, and absence of a saved plan.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

Manual desktop installs now fail whenever any local connection is not ready.

This exported waitForHostedMaintenance now gates three manual install paths:

• the sidebar pill (installLocalUpdate and onRestart in SidebarUpdatePill.tsx)
• handleDesktopUpdateButtonClick in LegacySidebar.tsx (Lines 3564-3565)
• handleButtonClick in SettingsPanels.tsx (Lines 227-228)

The helper behind it, waitForHostedMaintenanceInRegistry, rejects immediately in these cases:

• the catalog snapshot is not ready
• there are no hosted machines, for example when the local environment is disabled
• any hosted machine is not connected or not session-ready, for example a WSL backend that failed to start or a disabled WSL connection

In each case, the user sees "Could not install update: A local connection is not ready", and the desktop update does not install. Before this change, these buttons called bridge.installUpdate() directly. Installing an update is often how users recover from a broken local backend, so this blocks a common recovery path.

The helper has a second problem: it has no timeout. If a provider update stays in running, the install waits forever, and the button stays pending.

Rejecting is correct for the plan runner, where a not-ready local connection pauses the plan. Manual installs need a different gate. That gate should wait only for queued or running provider work on hosted machines that are connected, and it should never reject because a machine is unavailable.

✅ Confirmed as addressed by @Bil0000

Fixed in 0cc17105686e4a2e8243a1a62b2e0e5af403d1bf. Manual Restart in the pill, legacy sidebar and Settings now preserves the previous recovery path when a backend is unavailable and no busy hosted tool update was observed. Once work is observed, the helper tracks its environment/provider identity, including disconnected hosts, and requires a terminal result with readiness restored. Missing work or state rejects. There is no forced timeout. Automatic plans keep the strict maintenance gate. Added regressions for unavailable backends, queued/running work, readiness loss, and disappearing machines/providers/state.

@Bil0000 Verified the helper, manual callers, and regression coverage. Manual installs use waitForHostedProviderWork(). Automatic plans retain the strict maintenance gate.

The helper preserves recovery when no busy hosted work was observed. Once work is observed, it tracks provider identity and requires a terminal result with readiness restored. Missing work or state rejects.

Keeping no forced timeout is appropriate here: a timeout must not permit restart during an active tool update. My earlier timeout suggestion was unsafe.

I inspected the tests but did not run them.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

🟠 High sidebar/updateEverythingPlan.ts:214

After a restart on the unchanged source version, this return leaves the app item claimed and the plan stuck in awaiting-local until it expires. Check whether the claim owner is still alive here and pause for review if it has died.

No longer relevant as of a2562316fd2dafbd2b0d5f4d718f18cb0b10c8ef

Fixed in 0ee66d1048976d88e2eec0dfabfd7241fd80d632. On the unchanged source version, awaiting-local now checks the foreign owner. A live owner continues; an abandoned claim pauses for explicit Retry instead of waiting for expiry. Own claims and the not-applied marker keep their existing priority. Regression cases cover live/dead owners and concurrent claim, phase, or plan changes.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟠 High sidebar/updateEverythingExecution.ts:102

Retrying a paused plan can dispatch a second update for a server that is still updating in another window, and the original result then cannot settle its item because the claim ID has been cleared. When the other window’s update state is renderer-local, resolve(item, true) returns unknown; this block resets that item to pending without checking whether its claim is still alive. Preserve claims owned by live renderers before resetting items.

No longer relevant as of a2562316fd2dafbd2b0d5f4d718f18cb0b10c8ef

Fixed in 0ee66d1048976d88e2eec0dfabfd7241fd80d632. Retry checks foreign non-app claimed owners outside the transaction, then rechecks the plan, phase and exact claim inside it. Live or unchecked replacement claims block the whole Retry. Own idle, app, and settled unknown work remain retryable. Query failure blocks Retry without stopping storage. The final dispatch check also rejects a claim reset during admission. Added failing-then-passing recovery and dispatch regressions.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟠 High updates/DesktopUpdates.ts:673

When requestUpdateRestartPolicy(..., continueRunningThreads: true) is rejected, the backend keeps its persisted OFF policy, but this function still clears the publisher state and has already removed the local policy with Ref.getAndSet. Later restarts—including a retry with resume ON—therefore continue vetoing running threads. Retain the request and retry disarming until the backend acknowledges it; clear the publisher state only after acknowledgment.

No longer relevant as of 379b27065c79d610e67e3e1b2047e336382447d2

Fixed in 83c2155c96616e41d968ba2a59a69f47c1d096a1. A rejected rollback retains the request and publisher command. Every later install, including ON and legacy calls, retries that disarm before a stop or new OFF request. Repeated refusals leave the install failed without stopping backends. Tests cover ON, OFF and omitted choices, held acknowledgement, and later success.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟡 Medium sidebar/updateEverythingRun.tsx:497

When primary connection readiness is lost during the countdown, showPlan retains the expired restartAt and keeps the UI in phase: "countdown" after runUpdatePlan releases the undispatched claim and leaves the plan in local; “Restart in 0s” then remains visible even though no restart is scheduled. Preserve the countdown only while its deadline is in the future, and clear restartAt when it expires.

No longer relevant as of 379b27065c79d610e67e3e1b2047e336382447d2

Fixed in 979a11170c18a7e27a3ca2ab268f7a00a7ecdf62. The display keeps a countdown only while its deadline is in the future. After readiness loss releases the claim, an expired deadline clears and the capsule returns to preparing. Browser regressions cover the exact deadline and a later time, future countdown preservation, no install dispatch, and the installing display.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Preserve specific messages for expected install-preparation refusals.

The four preparation checks use Effect.die(new Error(...)). The outer Effect.catchCause treats these defects as unexpected install failures and passes DesktopUpdateUnexpectedActionError.message to recoverFailedInstall. This stores only "Desktop update install action failed unexpectedly." in the failure state and sends the same generic text to logUpdaterError.

Use typed Schema.TaggedError failures with fixed messages for these expected refusals. Handle them with Effect.catchTags before the generic catchCause, then pass their messages to recoverFailedInstall. Keep the existing admission refusals unchanged; those return accepted: false without entering the install flow. Add focused assertions for the specific preparation messages.

✅ Addressed in commits 83c2155 to 379b270

Fixed in 83c2155c96616e41d968ba2a59a69f47c1d096a1. One internal typed preparation error preserves the four specific refusal messages through recovery. Unexpected failures remain generic, and admission refusals still return accepted: false. The existing guard tests now assert the exact user-visible messages.

@Bil0000 The supplied code confirms that DesktopUpdatePreparationError preserves all four refusal messages through recoverFailedInstall. Unexpected failures remain generic, and admission refusals still return accepted: false. This addresses the finding.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift

A corrupt policy file prevents server startup.

make maps only NotFound to an empty state. A decode failure, or a read error other than NotFound such as a permission error or EISDIR, fails the UpdateRestartPolicy layer. server.ts provides UpdateRestartPolicy.layer into layerServerApplication, and Layer.launch(layerMakeServer) runs that composition. The server cannot start until the file is repaired or removed.

Falling back to an empty state would discard the veto state. isVetoed reads the set built from entries[].runIds. RestartContinuation.ts returns early when isVetoed is true, and ProviderRuntimeRecoveryService.ts excludes vetoed runs from continuation. An empty fallback can resume threads that the user kept stopped after an update. Handle an unreadable or invalid file so that vetoed runs stay blocked. Alternatively, report the failure with a clear recovery message. Do not silently clear the veto state.

✅ Confirmed as addressed by @Bil0000

Addressed in 379b27065c79d610e67e3e1b2047e336382447d2 using the stated clear-recovery-message option. Invalid or unreadable policy files still fail closed and remain untouched. The startup error names the exact path and tells the operator to restore a known valid policy or repair permissions before restarting. Only NotFound creates an empty state; runtime write errors have a separate generic message. Tests cover malformed JSON, invalid schema, a directory path, denied reads with preserved veto, missing-file startup and write-failure classification.

@Bil0000 Verified the fix in the current code. Load failures include the exact policy path and recovery instructions. Only NotFound initializes an empty state. Invalid or unreadable files still fail closed without changing saved policy data. Runtime write failures use a separate message.

The tests cover all the cases you listed, including preservation of the saved veto after a denied read. I inspected the tests but did not run them. This addresses the finding through the clear-recovery-message option.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

A failed policy acknowledgement write stops all desktop telemetry reception.

This is the only branch in the Stream.runForEach handler that can fail. It calls sendControlMessage, which can fail with DesktopTelemetryControlFailed or DesktopTelemetryControlStalled. When it fails, runForEach ends, and the trailing Effect.catch only marks health as degraded. After that, the server ignores every later hello, snapshot, and desktopUpdateStatus report until it restarts. Remote desktop updates and host-power telemetry stop working.

Handle the send failure inside this branch so that one failed acknowledgement does not end the read loop. The desktop publisher already times out after 15 seconds when the acknowledgement does not arrive. This branch also skips recordContact, which every other branch calls.

✅ Addressed in commits 83c2155 to 379b270

Fixed in 43b0706ce381b0e05206eb599152b6faea2d4ce8. Restart-policy messages record contact, and acknowledgement write failures are handled inside that branch. The read loop continues and the publisher keeps its existing acknowledgement timeout. A regression injects a control write failure, then verifies later hello, update status and telemetry snapshot messages are still received.

@Bil0000 Thanks. The supplied code confirms that restart-policy messages record contact and handle acknowledgement write failures locally. These failures no longer terminate the telemetry read loop. The reported regression covers subsequent message reception.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}

🟠 High sidebar/updateEverythingRun.tsx:451

Provider plan execution can install a version different from the persisted item.targetVersion and still mark the item done. This RPC omits the target, so ProviderMaintenanceRunner.updateProvider resolves the latest version instead; pass item.targetVersion in the RPC input to keep execution pinned to the saved plan.

No longer relevant as of 20af5e52035431b4a3d00e2099eeff774991470c

Fixed in 20af5e5203. New provider plans explicitly select latest, display that intent in the picker, and use the existing latest installer path. Saved numeric plans remain strict and send their exact target; a changed available version skips dispatch. This avoids pinning installs that have no manifest recommendation and closes the old N-to-N+1 race. The focused browser cases cover latest installers, legacy servers, and old numeric plans; the final changed-file gate passed 363 tests and the integrated browser batch passed 30 tests.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

🟠 High updates/DesktopUpdates.ts:667

If an OFF preparation rollback misses an ACK, every later install fails at releaseInstallRestartPolicy(true), even after the backend is removed, so updates stay blocked until the app restarts. The failed rollback retains the original instances, and subsequent installs request ACKs from those same IDs; reconcile them against the current pool before retrying.

No longer relevant as of 20af5e52035431b4a3d00e2099eeff774991470c

Fixed in f837441879. Rollback now keeps only original backend objects still active in the pool. Removed instances and same-ID replacements receive no old rollback request; live original instances still must ACK. Three RED regressions now pass, and all 42 DesktopUpdates tests pass. Native installs remain mocked.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.