A read-back that fails after CMO answered the write leaves the action unknown for good, its units and mission reserved #131

New issue

Closed

opened 2026-10-16 14:13:40 -04:00 by vinny · 0 comments

vinny commented

2026-10-16 14:13:40 -04:00

Owner

Laboratory trial tpl-surface-defensive-escort (live 2026-10-16, CMOnet 0.7.77) while the game's Lua dispatcher was busy:

18:00:49 missions.assign_units on OP-STRIKE-DJB-L1: the library tool answered ("Library tool answered; its read-back decides the effect"). At 18:01:02 its read-back failed with "socket command aborted: elapsed-time budget exceeded".
18:07:03 missions.deactivate on OP-STRIKE-L3: the same.

Both were left outcome_unknown ("Read back before any new command; no automatic retry"), so their missions and units stay reserved. Nothing reads them back again: verify_due only takes accepted_in_progress actions, and the flow does not call verification.read_back.

Worse, if the proxy lets the read-back expire in its queue ("queued command expired (not executed)", which the clock read saw at 17:52), the error carries execution_proven_absent. The coordinator then records the whole action as rejected, "No effect was sent", and releases its reservation, although CMO ran the write.

What failed was a read, after CMO answered the write. That read can be made again, never the write.

Laboratory trial tpl-surface-defensive-escort (live 2026-10-16, CMOnet 0.7.77) while the game's Lua dispatcher was busy: - 18:00:49 `missions.assign_units` on OP-STRIKE-DJB-L1: the library tool answered ("Library tool answered; its read-back decides the effect"). At 18:01:02 its read-back failed with "socket command aborted: elapsed-time budget exceeded". - 18:07:03 `missions.deactivate` on OP-STRIKE-L3: the same. Both were left `outcome_unknown` ("Read back before any new command; no automatic retry"), so their missions and units stay reserved. Nothing reads them back again: `verify_due` only takes `accepted_in_progress` actions, and the flow does not call `verification.read_back`. Worse, if the proxy lets the read-back expire in its queue ("queued command expired (not executed)", which the clock read saw at 17:52), the error carries `execution_proven_absent`. The coordinator then records the whole action as rejected, "No effect was sent", and releases its reservation, although CMO ran the write. What failed was a read, after CMO answered the write. That read can be made again, never the write.

vinny referenced this issue from a pull request that will close it,

2026-10-16 14:14:15 -04:00

Read a failed read-back again once CMO answered the write #132

vinny referenced this issue from a commit

2026-10-16 14:14:41 -04:00

Read a failed read-back again once CMO answered the write

vinny closed this issue

2026-10-16 14:14:41 -04:00

vinny referenced this issue

2026-10-17 15:30:53 -04:00

A write the proxy stopped past its time budget stays unknown for good, holding its mission #152