A 40000-unit sensor fleet on EU868 LoRaWAN takes firmware over the air. At the slowest data rate the application payload ceiling is 51 bytes and the sub-band duty cycle is 1%, so a 180 KB image is not shippable in any useful window. The team switches to binary deltas, which bring a typical release to about 9 KB. What happens when a device's running image is not the exact source image the delta was built against?

What happens, step by step

A binary patch is a sequence of copy-from-source and insert-literal operations addressed by byte offset into the source image. The patcher does not inspect what it copies. If the source differs from the assumed image by one byte at offset 4000, every copy instruction after that point reads the wrong bytes, and the output is garbage of exactly the right length.

1. The device receives all 9 KB and the transfer verifies - the delta's own signature is valid, because the delta really was signed by you.
2. The patcher runs and produces a reconstructed image. No error: the operations were well formed.
3. What happens next depends entirely on what is verified, and this is the trap. A signature over the patch says nothing about the result. Only a digest of the reconstructed image, carried in the manifest and checked before the new slot is marked bootable, catches it.
4. With that check and an A/B partition scheme, the device refuses the switch and stays on its old image. Without it, it boots garbage.

Where it amplifies

Devices diverge from the "known" image for reasons the build server cannot see.

• Per-unit data written at manufacture - calibration constants, a serial number, a radio trim value - inside the region the patch addresses.
• Flash bad-block remapping, changing physical layout per unit over the device's life.
• A partially applied earlier update, leaving a unit reporting version N that matches no N you built.
• The long tail. Devices offline through two releases are on N-3 and you built deltas from N-1, so there is no patch for them - and the dashboard shows them as "pending" rather than "impossible".

What the user sees

With the digest check: nothing. The rollout stalls at 91%, no device reports an error, and the remaining 9% quietly keep refusing. That is the good outcome and it is almost invisible, which is why the alert must be on the share of devices that attempted and declined, not on rollout percentage.

Without it: units that boot into nothing, with no recovery path over the air, because the full image that would repair them cannot be delivered on this bearer. The recovery is a van.

What stops it

The device must state what it is running, and the server must answer that exact question.

1. The update request carries a digest of the running image, not a version string - a version is an assertion, a digest is a measurement.
2. The server returns either a delta built from precisely that digest, or a full image, or an explicit "no path from here" that is visible on a dashboard.
3. The manifest carries a digest of the reconstructed image, verified before the slot is marked bootable. RFC 9019 (April 2021) puts that machine-processable manifest at the centre of the architecture for exactly this reason.
4. The server keeps every image it ever shipped, which is what building a delta from the device's real base requires - the hidden cost that makes teams abandon deltas.

When this is the wrong answer

On any bearer where the whole image fits in the maintenance window, ship the whole image. Cellular, Wi-Fi and Ethernet make the entire problem above disappear for the price of bandwidth nobody is billing you for by the byte. Deltas are not an optimisation you reach for; they are what you are forced into when the physical layer makes a full transfer impossible.

And if deltas are forced on you, the honest design statement is: deltas with a verified base, a full-image path on a second bearer where one exists, and a site visit priced into the business case. A fleet on constrained radio with no out-of-band recovery has accepted a per-unit field-service liability, and that belongs in the budget rather than the risk register.