Updates
Imagine an operator downloads an update successfully, but the new process cannot pass its health probe. Installing those bytes permanently would turn a recoverable deployment into downtime.
AppCore updates treat application artifacts as opaque bytes. The runtime validates identity, version movement, compatibility, authenticity, checksum, staging, activation, health, and rollback boundaries. It does not inspect application code or perform domain schema migration.
Why is a newer file not automatically a valid update?
An update request contains the installed application identity, current version, and selected channel. The provider may return a candidate descriptor. The coordinator rejects the candidate if:
- application ID differs;
- channel differs;
- candidate version does not advance the installed version;
- the active artifact has a different application ID;
- candidate build ID reuses the active build ID;
- candidate version does not advance the active version;
- runtime requirement or protocol version is incompatible.
What proves an artifact is allowed?
Production coordinators require an explicit artifact authenticity verifier. Ed25519 verification uses deployment-owned trust roots. Trust roots can be active, deprecated, or revoked. A revoked key rejects every artifact.
Policy can also allow exact channels and origins before signature verification. Development-only unsigned local artifacts require a compile-time feature and strict file-root checks; this is not an automatic fallback.
The signing payload covers stable descriptor fields: application ID, application version, build ID, channel, runtime requirement, protocol version, artifact reference, SHA-256, and size.
What happens between download and commit?
The two-phase path exists for process-level health verification. A parent can stage and activate a candidate, restart/probe the child, then commit or rollback depending on observed health.
When does rollback happen?
If activation fails after the previous artifact existed, the coordinator rolls back to the previous artifact and reports the attempted descriptor plus reason. Fault-injection points exist after selection, verification, staging, activation, health verification, and before commit so tests can prove rollback behavior.
Why does update code care about filesystem shape?
Update file reads reject symlinks, non-regular files, and files above the configured byte limit. Activation revalidates staged size and SHA-256 before installing immutable build artifacts. Existing build paths are not overwritten unless they are exact-byte idempotent reuse.
Limitations
- Updates do not perform business schema migrations automatically.
- They do not prove the new version is semantically correct; health checks only test the configured runtime probe.
- They do not manage external deployment credentials.
- Production requires an authenticity verifier. Unsigned local artifacts are development/test-only.
- Rollback is scoped to the artifact store and activation state; it cannot undo external side effects created by the new application version.
Continue with security model.
Explicit host lifecycle composition
HostUpdateFlow composes ActivationAdapter, UpdateRecoveryGate and the existing V2 journal. Deployment owns one external lock, authenticated staging, drain deadlines, installation-bound snapshots, process start/stop and actual readiness. Prepare persists intent before callbacks; activation repeats idempotent drain/snapshot/preparation and seals writes before calling the host. Every callback must honor deployment-owned execution bounds. Pending receipt survives interrupted phases. A prepared receipt after interrupted activation does not prove that nothing became active: inspect actual host state through recover, or require manual review. Health failure durably requests rollback. Host commit runs before recording committed; ambiguous commit never reports completion. Rollback requires a re-probed observed identity before RecordRolledBack. Keep previous artifacts/data until real health and recoverable completion. Terminal receipt replays validate digests. Version must advance with distinct build, platform/target and hash; same-version builds are not an automatic upgrade. No Tauri, container or process manager dependency is introduced.