What happens
The update/upgrade maintenance window adopts the installed version only from the action's success value (MaintenanceWindowOutcome.installed_version). If crate::upgrade::run_upgrade returns an error after it has already replaced the executable, the restore starts the new binary but checks readiness against the old binary's identity. It then waits 3 minutes and fails with protocol readiness is identity mismatch (... expected ... version=<old>). This is the same failure the beta.53 updater hit, where post-update exited non-zero.
One path in origin/master can still do this. publish_release_at renames the new binary over the running executable (publish_member) and then calls stabilize_installed_executable. On macOS that runs codesign --force --sign -, and a codesign failure returns Err from run_upgrade. By then the binary is already replaced.
The post-update half of this class is fixed in the update-path fixes PR: a post-update that cannot run after an install is now reported as a failed refresh and keeps the version. This install-step half is macOS-only, and I did not verify it on macOS.
Expected
Once the executable is replaced, the restore validates the installed binary's version, and the codesign failure is reported beside the upgrade instead of being swallowed into an identity-mismatch wait. For example, record the installed version as soon as publish_member succeeds.
What happens
The
update/upgrademaintenance window adopts the installed version only from the action's success value (MaintenanceWindowOutcome.installed_version). Ifcrate::upgrade::run_upgradereturns an error after it has already replaced the executable, the restore starts the new binary but checks readiness against the old binary's identity. It then waits 3 minutes and fails withprotocol readiness is identity mismatch (... expected ... version=<old>). This is the same failure the beta.53 updater hit, where post-update exited non-zero.One path in
origin/mastercan still do this.publish_release_atrenames the new binary over the running executable (publish_member) and then callsstabilize_installed_executable. On macOS that runscodesign --force --sign -, and a codesign failure returnsErrfromrun_upgrade. By then the binary is already replaced.The post-update half of this class is fixed in the update-path fixes PR: a post-update that cannot run after an install is now reported as a failed refresh and keeps the version. This install-step half is macOS-only, and I did not verify it on macOS.
Expected
Once the executable is replaced, the restore validates the installed binary's version, and the codesign failure is reported beside the upgrade instead of being swallowed into an identity-mismatch wait. For example, record the installed version as soon as
publish_membersucceeds.