Repository navigation
Keep the desktop app recoverable after update preparation fails #544
Description
An observed desktop update from source 5e6b0dfe to 292cdb1a stopped the app during preparation, then refused with Process inspection failed; signal withheld. The helper retained the previous app/state but wrote a non-terminal blocked journal and did not reopen the app. Subsequent launches hit the native activation startup fence and exited through stderr only, leaving no visible recovery path.
Source inspection at 292cdb1a2c84f5b4539793636e2bfac674f9af92, re-anchored against db0388cb, identifies five connected gaps:
- A refusal before bundle/state replacement leaves
blockedrather than a proved terminal recovery outcome and does not relaunch the previous app. - Startup refusal is invisible when launched normally from the desktop.
- Recording
blockedloses the earlier phase, while the existing reconciliation entry requires an already-running app. - Process identity relies on strict
pstext parsing and discards the diagnostic output. The precise incident trigger remains unknown; local probes did not reproduce it. - The next update executes the helper embedded in the currently installed app, so delivery of a fixed helper needs explicit first-transition qualification.
Done when:
- Proven failures before replacement preserve the previous app/state and reopen the app; unknown or potentially effective failures remain held.
- Recovery retains sufficient phase/effect evidence and a visible startup error or recovery route that does not depend on an already-running app.
- Process identity remains exact and fail-closed, with bounded diagnostic evidence and supported-macOS qualification.
- Existing desktop journal compatibility, recovery locks, paired rollback, and activation verification remain intact.
- Focused regression tests and a disposable packaged-Mac acceptance run cover the observed failure chain and first update into the fixed build.
A detailed planning-only Engineering Spec, spec.jones-update-recovery-hardening, covers the desktop slice alongside separate VPS recovery work. No implementation or rollout has started. Exact process-inspection trigger and verification-delay causes remain open investigations.
Related: #490 tracks broader packaged desktop qualification; #542 tracks the distinct VPS failed-operation ledger problem. This issue records outstanding work and grants no implementation or host-operation authority.
Activity
test(updates): observe fixture-bound launcher reconciliation IPC
test(updates): exercise fixture-bound legacy reconciliation
test(updates): preserve held legacy recovery evidence
test(updates): observe live launcher acceptance before recovery faults
test(updates): exercise accepted failure settlement and fresh installs
test(updates): observe unsettled Install refusal before reconciliation
Mjones13 commentedon Oct 29, 2026
Campaign JS-A11 current-source attribution at
88523084054b1159d31ab5ec183a71cfa7be3a5d(all cited merge commits verified ancestors):ea598fde1e21acbf4b63a87f78ee72a56abf039a, implements proved pre-effect settlement/reopening and retains unknown-effect holds.92043de32b4f28eb429dfffd04453407c151bb72, adds the startup classification/recovery and visible refusal path before state initialization.b581fdc218e84a4a31a2862a1ce508abfd8634a4, completes kernel identity handling with strict historical-proof compatibility. The underlying original incident trigger remains unknown; source tests do not establish that trigger.3f9ab4a2d709e08bbf153751094b9af44d223122, advances recovery harness controls and expressly does not qualify the actual package matrix. The original body’s “no implementation ... has started” is now stale; these source slices are delivered. Their PRs retain exact checks and platform skips.The active App Installs and Background Updates owner (
146b5dc0-e3b4-4755-be07-8812bc8dafbc) retains packaged qualification. It confirmed its current read-only candidate is frozen at3f9ab4a2/tree5fe8a41d: seven actual Linux crash/restart prefixes and released292cdb1aarchive/admission compatibility passed. Full recovery matrix and disposable packaged-Mac failure-chain/first-transition acceptance remain unproved; Linux evidence cannot substitute for them. No competing recovery implementation or installed transition is being started by this campaign.Keep open. Remaining actor: that existing qualification owner; resume on its complete attributable package/Mac receipts and, separately, any owner-authorized operational window. Original journal, recovery-lock, paired-rollback and activation-verification criteria remain in force. No installation/restart/adoption is authorized or claimed here.
fix(updates): give packaged recovery fixtures valid loopback ports
fix(updates): observe retained failures in packaged recovery fixtures
fix(updates): validate native reconciliation refusal responses
fix(updates): await native completion before fixture shutdown
fix(updates): defer active-source fixture drift until runtime readiness
Mjones13 commentedon Nov 5, 2026
Additional packaged-macOS evidence from an owner-authorized laptop update on November 5, 2026:
d37ebd88db3cada84d025eeaca01b2a323e342dfstaged exact candidate7b391d894f0edb4d135208c25c50653626bc59ee. Native preparation failed withNative preparation transport failed (TIMEOUT)before activation. The preparation was withdrawn and retired, with no bundle swap.Installing · restarting) with only Check again. Repeated refresh and app restart did not settle it. Installed-source inspection showsrunLaptopreturning the unchanged plan when the operation binding already matches, even after a failed result;reconcilealso skips the install step.clone-requiredpolicy. Its receipt proves a complete database/settings clone, previous app preservation, exact-process shutdown, swap and LaunchServices launch. Fresh HTTP readiness and the desktop build footer both verify the candidate version/source. No partial backup or fabricated preparation/continuation receipt was used.Installing · restarting; Check again does not reconcile the successful ordinary recovery. The actual installation is healthy.Please retain this as a concrete regression case for terminal preparation-failure settlement, renderer connection recovery, and reconciliation against a verified replacement generation. This operational recovery did not implement a source fix or qualify the broader packaged failure matrix.
Mjones13 commentedon Nov 6, 2026
Related recovery work delivered in #854, #855 and #857. These changes reconcile retired desktop install status, distinguish verified ordinary recovery from warm commitment, admit strictly validated completed receipt-only staging remnants before native effects, and provide source-qualified reconciliation for abandoned macOS preparation jobs. Required checks and applicable packaged platform/lifecycle qualification passed.
The explicitly requested fleet update is operationally verified: desktop and three existing servers run the same qualified source
8dd90ff9e3d41e7ba9ac1c81bceb4f973734314b; retired desktop status is cleared, native server transactions committed, and normal update checks return current or a qualified newer build. No partial state copy was accepted as a full backup.Keeping this issue open: these bounded repairs do not satisfy every broader startup visibility, process-inspection diagnostic, and first-transition recovery criterion above. The original transient native image-attachment cause and historical admission delay were not established; no causal fix for those is claimed.