The health gate and automatic rollback

The health gate is the last phase of an update: after the new version is installed and the daemons restart, the system checks whether the robot is healthy and rolls back automatically if it is not.

The phases

preflight → downloading → verifying → swapping → health_gate

Any of them can fail, and every failure ends with the robot back on the version it was running — not half-dead.

What it means for development

Pushing your own build is a safe operation. What scripts/dev-push.sh installs goes through exactly the same path — signature, artifact hash, compatibility, health gate, automatic rollback. The only difference is which key signed it.

A build that will not come up is reverted. You cannot push the board into a brick.

A success that looks like a bug

When the gate works, it sometimes reads as a failure:

On a dev board, apply daemon without --ref installs the stable release. If that release predates a daemon which now has a unit file on the board, the unit’s ExecStart points at a binary the older release does not contain → the restart fails → rollback.

You see “the update failed”, and what actually happened is the gate saving you.

The robot may have rolled back already

Automatic rollback does not interrupt you; it only writes to the log:

robotctl update log
journalctl -b -u robot-boot-check