Command Validity Window

A command is issued to a device that is offline. It queues. Three hours later the device reconnects and executes it — into a situation that no longer resembles the one the command was issued for.

A validity window attaches a deadline to the command. The device evaluates it on receipt and discards anything past its window, reporting the discard rather than acting.

Why queued commands are a distinct hazard

Most distributed-systems intuition favours durable delivery: queue it, retry it, guarantee it arrives. For commands that actuate something in the physical world, delivery guarantees are the wrong goal — the guarantee that matters is that the command is either executed while it is still correct or not executed at all.

Unlocking a vehicle three hours after the request, adjusting a setpoint after the shift ended, or dispatching a device that has since been recovered are all failures produced by a system doing exactly what it was told.

Implementation patterns

• An expiry timestamp on every actuating command, sized to the action's meaning rather than to a default.
• Acknowledgement of execution, and of expiry, so the issuer learns which happened. Silence must not be read as success.
• Device-side evaluation, because only the device knows when it actually received the instruction — a server-side timeout tells you the command was not acknowledged, not whether it was executed.
• Idempotency, so a re-sent command within its window does not double-execute.
• Local safety conditions checked before execution, since the platform's view of the device's situation is stale by definition. A command to move should not execute if the device's own sensors say it is occupied.
• A distinct state for devices that have not reported recently, rather than showing the last known state as though it were current — presenting stale state as current is what sends operations teams to places where nothing is.

Industry example

Micromobility and connected-equipment operators learn this quickly: a fleet of tens of thousands of vehicles generates a continuous stream of lock, unlock, alarm and disable commands, and a meaningful fraction target devices that are unreachable at that moment. Without expiry, a reconnection event delivers a backlog of stale instructions simultaneously — which is both operationally wrong and a visible safety concern.

The related design point is that the operational product is an ordered list of what to do next, not a map. That reframing shifts investment from tracking toward prediction and dispatch, and it makes command staleness a first-order concern rather than a detail.

Failure scenarios

• Unbounded command queues, delivering a stale backlog on reconnection.
• No execution acknowledgement, so the issuer cannot distinguish executed from lost.
• Server-side expiry only, which cannot know when the device received the command.
• No local safety check, so a stale-but-valid command executes into an unsafe situation.
• Last known state shown as current, which is the same class of error in the read path.

Trade-offs

Short windows mean commands to intermittently-connected devices frequently expire, and the operator must reissue — which is friction, and is correct, because reissuing is a deliberate act taken with current information.

The tuning is per command type: a diagnostic request can tolerate a long window, an actuation affecting physical safety should have a short one. A single global expiry is wrong in both directions, and choosing per command is the small amount of design that makes the mechanism useful rather than annoying.

Interview question

"An operator sends an unlock command to a vehicle that is offline in a basement car park. It reconnects four hours later. What should happen, and what should the operator have seen in the meantime?"