PWA update is accepted but detached updater exits silently on macOS

[ubuntudroid]

Summary

Triggering an update from the PWA appears to do nothing on macOS. The API accepts the request, but the detached updater exits before handing off to the new version. Running collie update interactively on the host succeeds.

Environment

• macOS arm64
• Updating from Collie 1.11.0 to 1.12.1
• Collie running through its LaunchAgent

Observed behavior

1. Press the update button in the PWA.
2. The request returns successfully.
3. No update progress or failure appears in the PWA.
4. Collie remains on the old version.
5. Running collie update in a host shell completes the update.

Three PWA attempts were accepted. Each staging log ended at:

checking that 1.12.1 runs here

No LaunchAgent restart followed those attempts.

At the same timestamps, macOS AMFI/Gatekeeper logged that the downloaded candidate was ad-hoc signed or had an unknown certificate chain. spctl --assess --type execute also rejected the candidate.

The later interactive update reached the service handoff and successfully restarted Collie.

Likely cause

The detached updater fails while smoke-testing the freshly downloaded macOS binary. The release binary is ad-hoc signed and not notarized, and its execution behavior differs between the LaunchAgent/background context and an interactive shell.

This attribution is high confidence, but the exact subprocess failure cannot be recovered because the initial detached updater discards stdout and stderr.

Additional issue: failure is invisible

POST /api/update returns 202 once the updater process is spawned. The process is detached with stdout and stderr ignored. If it exits before creating a run record, the PWA receives no durable error and returns to an idle state.

Expected behavior

• A PWA-triggered update should complete under the same conditions as collie update.
• If the updater exits early, its error should be retained and displayed in the PWA.
• The API should not report a successfully started update until a run record or equivalent acknowledgement exists.

Suggested fixes

1. Sign and notarize macOS release binaries.
2. Persist early detached-updater failures.
3. Require an updater acknowledgement before returning a successful start response.

The separate amber path-link doctor warning did not block these requests and does not appear to be the cause.

[AltanS]

Thanks @ubuntudroid, your report found a real bug, and it is not signing. The LaunchAgent passes COLLIE_PLUGIN_ROOT (the old install) to the detached updater, and the smoke test runs the new binary with it, so collie version reports the old version and the check fails; an interactive shell has no such variable, which is why collie update works there. You can confirm it on your Mac without changing anything: COLLIE_PLUGIN_ROOT=<the value in your LaunchAgent plist> <your versions dir>/1.12.1/bin/collie version should print the old version. The fix passes the candidate's own root to the smoke test, keeps the failure's reason and shows it in the app instead of dropping it, and writes the detached updater's output to a log; it ships in 1.13.1, credited to you in the changelog.

[AltanS]

Thanks @ubuntudroid, 1.13.1 is out with the fix. A phone-started update now runs the new version under its own install folder, so the start-up check reads the right version, and the build and restart steps do the same. The update to 1.13.1 itself still runs your old updater, so run collie update in a terminal once; from then on the phone button should work. If a later update gives up before the switch, the phone ends on "The update failed on " with the reason instead of closing, and the updater's own output stays in update-runner.log in the state folder. If that happens, please post the reason and the log here, because they would show whether signing plays a part after all. You are credited in the changelog.