Fleet status can remain `available` while a device is actively busy

[hilaus-arm]

Summary

I observed a mismatch between fleet-facing device status and the device’s actual runtime state.

A device can be actively handling work, while fleet discovery still reports it as availability="available".

This makes orchestration unreliable because callers can select a device that is already occupied.

Reproduction

1. Start a device whose runtime status can change over time.
2. Cause the device to enter a busy state.
3. Check the device-specific runtime state and confirm it is busy.
4. Check fleet discovery / list_devices(...).
5. Observe that the device may still appear available.

Expected behavior

Fleet-facing status should reflect the device’s current runtime status closely enough for orchestrators to make correct scheduling decisions.

At minimum, a busy device should not continue to appear available in fleet discovery.

Actual behavior

The device can be actively busy while the registry / fleet view still shows it as available.

Suspected cause

The runtime appears to snapshot device status during initialization and reuse that stored payload for registration.

The heartbeat path appears to support dynamic fields through a heartbeat provider, but does not automatically propagate the device’s current status on each heartbeat.

That can leave the registry with stale status even if the device’s local runtime state has changed.

Why this matters

This can lead to:

• double-dispatch onto a single busy device
• misleading fleet state in tools and UIs
• unnecessary compensating logic in orchestrators that should be able to trust fleet status

Notes

This appears to be a generic status propagation issue in the runtime / registration / heartbeat path, not a problem specific to one particular device implementation.

[soupat]

Ran into the same gap recently and prototyped a fix on the runtime side. Sketch of the change:

• PresenceAnnouncer.update_status(status: dict) -- replaces the advertised status and triggers a burst announcement (alongside symmetric update_capabilities / update_identity setters).
• DeviceRuntime.update_presence(capabilities=..., identity=..., status=...) -- public hook a driver calls when any of the three changes.

That gives drivers a way to push a fresh DeviceStatus into presence, which doesn't currently exist -- the registry is stuck with whatever was captured at DeviceRuntime.__init__.

What this doesn't address, and I think is the core of #24:

1. The heartbeat path is unchanged. If a HeartbeatProvider returns a status with availability="busy", that still doesn't propagate to presence automatically. The runtime would need to call update_presence(status=...) from the heartbeat loop, or the announcer would need to subscribe to heartbeat output.
2. Drivers that want busy/available transitions reflected in fleet discovery have to opt in by calling update_presence(status=...) themselves -- there's no policy yet for "always mirror current heartbeat status into presence".

Happy to open a PR with the update_* setters if useful, and a separate one wiring heartbeat -> presence once we agree on the policy. Main design question for that second one: every heartbeat (simple, but burns announcement bandwidth) vs. only on-change (cheaper, but needs a comparator).