OTA Campaign Supersession: Stop an Old Job from Reinstalling After a New Release
Persist a high-water mark for accepted campaign intent, then check it again immediately before installation dispatch. An older job must not become eligible merely because its timer fires late, its download finally finishes, or its retry arrives after a newer campaign. Keep that desired-intent ordering separate from any installation already in progress.
This is an original orchestration policy for a device managed by one defined campaign authority. It is not an RFC wire format, a protected anti-rollback implementation or an installer feature. The transition cases below are proposed qualification fixtures; no campaign service or target device was exercised.
1. Separate campaign order from firmware security order
RFC 9124 section 4.3.1 distinguishes a manifest’s monotonic sequence number from firmware version. Its information model permits an older payload under a newer manifest. That distinction is useful here, but a scheduler’s campaign generation is yet another value with its own purpose.
| Value | Question answered | Does not establish |
|---|---|---|
| Campaign generation | Which management intent supersedes earlier jobs? | Whether a payload satisfies boot security policy |
| Artifact identity | Which exact approved content is selected? | Whether this campaign still owns dispatch |
| Manifest or boot security version | Which authenticated update or executable is acceptable? | Which operator campaign is currently desired |
| Installation attempt identity | Which execution produced this result? | Whether it remains the latest desired campaign |
A recovery campaign may intentionally select older application firmware while using a newer campaign generation. It still must satisfy every independent signature, compatibility, security-counter and data-schema restriction. Incrementing a scheduler number cannot authorize a forbidden downgrade.
2. Define the comparison domain before using a counter
Bind each request to the authenticated authority, device or target scope, generation, immutable intent digest and action. The intent digest covers the fields that must remain stable, including selected artifact and applicable scheduling policy. A payload digest alone cannot distinguish two campaigns with different permissions.
Only compare generations inside the same defined authority namespace. If management ownership changes or the authority restores an old database, require an explicit authenticated reconciliation process. Do not compare unrelated counters numerically or accept an arbitrary new epoch merely because its label looks newer.
Use a sufficiently large bounded integer with checked parsing and a defined exhaustion policy. Do not wrap the value back to zero. Reject unauthenticated, malformed or inapplicable requests before advancing persistent ordering state; otherwise an invalid high number could suppress legitimate work.
3. Apply a deterministic acceptance table
Let H be the highest accepted generation and D its immutable intent digest. Evaluate each authenticated, applicable request against the complete persisted record.
| Incoming request | Decision | Persistent effect |
|---|---|---|
| Generation below H | Report superseded; never dispatch it | Do not lower H |
| Generation equals H and digest equals D | Return the current intent and attempt status | Do not create another installation automatically |
| Generation equals H but digest differs | Hold as conflicting authority data | Do not replace the accepted intent silently |
| Generation above H, valid new install intent | Accept as the new desired campaign | Persist its generation and digest before enabling dispatch |
| Generation above H, valid no-install intent | Suppress older queued campaigns | Persist a tombstone with the new generation |
A tombstone records that the current intent is to perform no new installation. Deleting the old job alone is insufficient: a delayed copy can recreate it after deletion. Preserve the ordering evidence even when no payload remains queued.
Specify retry policy separately. A duplicate of the current request can return a failed attempt’s result without immediately retrying it. If retries are allowed, they need an explicit current-generation attempt decision, resource budget and installation eligibility check.
4. Keep desired intent separate from an active writer
RFC 9019’s terminology separates the status tracker, firmware consumer and bootloader roles. Reflect that separation in the application: accepting a newer management intent does not mean a running installer can be interrupted safely.
Store both the latest desired generation and the identity of any active or possibly-dispatched installation. A new campaign can supersede queued work while the old operation still finishes under its qualified completion or recovery policy. Do not start the new writer concurrently or relabel the old operation as canceled.
When the old operation completes, attach the result to its original attempt. It may change observed installed state, but it must not overwrite the latest desired campaign. Reconcile the actual device state and then evaluate whether the newer campaign is still eligible to dispatch.
5. Fence every delayed path at dispatch
Carry the generation and intent digest through timers, download callbacks, approval responses and retry jobs. Immediately before dispatch, compare both against the current durable desired record under the same state owner that controls dispatch admission.
A callback matching an old in-memory object is not enough if a newer decision has been persisted. Conversely, a persisted supersession must not be acknowledged as active while an unsynchronized worker can still dispatch the previous job. The persistence and publication sequence needs a tested crash-consistency contract.
After reboot, restore the ordering record before loading delayed jobs. If the record is corrupt or missing, enter reconciliation rather than choosing the largest number found in arbitrary cache files. Preserve the actual installation state while management ordering is unresolved.
6. Test reorderings that reveal policy mistakes
- Accept generation 42, then deliver an old generation-41 timer and download completion.
- Repeat generation 42 with identical intent, then with a different artifact.
- Accept a generation-43 tombstone and replay generation 42 after reboot.
- Receive generation 44 while a generation-42 installation is still active.
- Deliver generation-42 completion after generation 44 becomes desired.
- Submit an invalid high-number request and verify that H does not advance.
- Restore the management service from an older snapshot and reconcile its authority state.
Require a saved explanation for every rejected or deferred event. Host models can exercise ordering rules; actual persistence, installer recovery and authority transitions need integration tests. The model alone does not establish tamper resistance or power-loss safety.
Hypothetical delayed reinstall
A gateway completes campaign 42 and later accepts campaign 44. A cached retry for campaign 42 wakes after reboot. Because the restored high-water record is 44, the old retry returns superseded without dispatching, even if its artifact remains validly signed.
If campaign 42 had already been installing when 44 arrived, its eventual result would remain recorded honestly. The device would then reconcile and evaluate 44. This two-record approach prevents stale management work from regaining control without pretending that supersession undoes an active installation.
