Command Retry and Idempotency: Prevent Duplicate AV Actions

Retry an AV command only after deciding what a duplicate would do. Setting a device to a desired state, toggling that state and advancing to the next cue are different operations. When the response is lost, the device may already have acted, so silence alone does not make replay safe.

The correct retry policy belongs beside the command definition. A global retry count applied to every button hides differences that become serious during network interruptions or controller restarts.

Classify commands by observable effect

RFC 9110 defines idempotency for HTTP methods. The same reasoning helps evaluate other control protocols, although their device manuals determine actual behavior: would repeating the request produce the same intended effect, or an additional action?

This table classifies intent, not universal command guarantees. A nominal set operation can still reset a process or have other side effects on a particular device.

Distinguish rejection from uncertainty

An explicit application error usually provides a reason to fix parameters or state before trying again. A transport timeout provides less information. If the device executed the request and its response was lost, sending again can duplicate the action.

RFC 8085's UDP guidance places reliability handling at the application layer. Request identifiers and receiver-side duplicate suppression can help only when the protocol actually defines and supports them. Do not append a home-made identifier to a vendor command and expect it to be recognized.

Record transaction outcome as confirmed, rejected or uncertain. Keep that classification through reconnects and controller restarts when the project requires recovery across them. Replacing uncertainty with success or failure merely to simplify the UI loses important operational information.

Prefer reconciliation for desired states

After communication returns, read the current device state. If it already matches the approved target, the workflow can continue according to its completion criteria. If it differs, issue a new, deliberate state-setting operation within the allowed retry budget.

For relative actions, consider whether a supported absolute command can express the same operator intent. Setting an input directly is usually easier to reconcile than repeatedly pressing Next Input. If only relative control exists, acknowledge that limitation in the design and acceptance record.

Use bounded retries with spacing and an overall deadline. Stop when a newer operator request supersedes the old target. Otherwise a late retry from Close can arrive after Open and produce a confusing reversal.

Test the ambiguous middle

A useful bench test deliberately withholds the response after the action has happened. A test server can model this without risking real movement or show interruption. Verify that desired-state operations reconcile and duplicate-sensitive operations stop for the approved decision path.

Also test two quick operator presses, a reconnect and a controller restart. Count physical actions or cue changes, not only sent packets. The result should explain exactly how many actions occurred and what the operator sees.

Keep an audit line for each automatic retry: original transaction, reason, attempt number and final decision. If a newer operator request supersedes the target, record which older work was cancelled. These records make duplicate-action reports explainable after the event. They also expose profiles that accidentally classify a reset, counter clear or scene trigger as an ordinary state setter merely because those operations share the same network transport and response parser.

Apply this policy to the wider opening and closing workflow. Bring the command classification to a partner consultation when evaluating which device operations and feedback a controller can safely automate.