octoturgeandClaude Opus 5 0f57717378 Test that a late command failure reaches the cloud ...

The outbound queue had no coverage, and it is exactly the kind of code
that looks right and does nothing: the failure path only runs minutes
after the command was answered, so nothing in the ordinary flow would
notice it was missing.

Stands up a real websocket server and runs the real `uplink::run`
against it, asserting two results for one command_id in order - ok:true
on acceptance, then ok:false carrying a reason that names what went
wrong. That the id repeats is the contract, not a bug to deduplicate.

It touches no printer and makes no outbound request: the fleet is empty
and `dispatch` checks the fleet before downloading, so the command fails
on a lookup. The unreachable URL is on port 1 so a regression that did
reach the network fails fast rather than hanging on a real host.

Verified to fail without the feature, not just to pass with it: stubbing
out the send makes it time out waiting for the second result. That check
is worth doing by hand here - the go2rtc RTSP test asserted the absence
of a config key and passed the whole time the server was open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-10-18 21:52:05 +00:00

..

fixtures

Derive the AMS mapping from the project, and blink on completion

2026-10-15 21:27:24 +00:00

push_status_parsing.rs

Model vt_tray and the stage fields, and use them

2026-10-15 21:37:20 +00:00

uplink_late_result.rs

Test that a late command failure reaches the cloud

2026-10-18 21:52:05 +00:00

uplink_protocol.rs

Send the edge token on the upgrade, not in the hello

2026-10-17 14:00:05 +00:00