Schema Migration Policy Belongs in the OTA Safety Model
Rollback is only safe when persistent data remains readable by the previous firmware or a migration policy accounts for the change.
TOPIC
OTA & Fleet
Lessons, explainers, experiments, and implementation notes.
Firmware Compatibility Should Be Derived from the Enrolled Device
Release metadata is safer when it comes from authoritative device capabilities instead of copied operator input.
A Failed Canary Must Block Stable Promotion
Success evidence loses meaning if failed or rolled-back assignments are ignored during promotion.
STABLE Should Mean a Device Actually Ran the Release
A release should not become stable merely because an administrator clicked a promotion button.
Store Device Enrollment Secrets as Hashes When the Server Only Needs Verification
If a token only needs to be checked, retaining the plaintext creates unnecessary breach impact.
Terminal OTA Events Need a Release ID
Rollback and validation failure are too important to infer from an unscoped status string.
A Sticky Heartbeat Result Almost Became a False OTA Rollback
Telemetry from a previous release must not be allowed to mutate the state of a newly assigned release.
An OTA Download Finishing Does Not Mean the Update Is Finished
A full OTA progress bar proves that a file transfer completed. It does not yet prove that the device booted the image successfully or that the required product functions still work. Update success spans several states.
OTA Compatibility Is More Than a Version String
A firmware artifact can be newer and still be unsafe for the target partition table, bootloader or hardware revision.
Release State and Release Channel Drifted Apart
A release promoted to STABLE was still carrying old channel metadata, creating two competing sources of truth.