Revision fencing and stable operation IDs in AgentPlat

Two duplicate-looking requests can mean different things

Two workers may attempt a transition from the same revision. Separately, one client may retry an operation because it lost the response. The first is a concurrency conflict; the second may be another delivery of the same logical work.

The Rooms API reference documents compare-and-set writes and stable identities. Treating both situations as a generic “retry request” hides the evidence needed to decide what should happen next.

A stale revision requires a fresh decision

An operation carrying expectedRevision describes the state the caller believed it was changing. If another transition wins, re-read the resource and evaluate whether the original action still makes sense.

In an illustrative approval workflow, a reviewer may have requested another revision while a second client tries to accept the previous state. Blindly replacing the revision number and resubmitting would turn conflict handling into an unintended decision. The application must preserve the user's intent while respecting the new state.

A retry should retain its logical identity

The coordination worker retains operation IDs across retries and restarts. Creating a fresh ID after every timeout can make a repeated attempt look like unrelated work.

Keep identity attached to scope and payload semantics as required by the selected operation. An idempotency key is not permission to change the target or content of an already identified action.

Check the runtime digest as well as the identifier

The governed runtime facade documents rejection when an operation is repeated with a different input digest. Its durable store and idempotency ledger have distinct integration responsibilities.

This gives a concrete test: retry the same intended operation, then attempt reuse with changed inputs. Inspect the retained outcome and rejection separately. Do not assume a successful duplicate request proves that mismatched payload reuse is also handled correctly.

Carry the boundary into the external sink

A local revision or operation ledger cannot enforce a remote system's atomicity. The effect controls guide requires the sink to bind its own identity, payload and scope and reconcile uncertain results.

• Record which state revision a transition expects.
• Keep one logical identity across genuine retries.
• Reject changed input under an existing operation identity.
• Re-read after conflicts instead of blindly advancing revisions.
• Test remote outcome reconciliation as a separate concern.