The change request lost its response.
What would justify another attempt?

Consider a proposed manufacturing workflow in which an assistant changes a supplier's document-review status. This is a review scenario, not an observed deployment. Microsoft's Retry pattern describes the central ambiguity: a service can process a request successfully and fail to return its response. A timeout therefore establishes neither failure nor success. Our proposed decision record starts with the original destination and operation, relevant interface version or configuration if known, submitted content, identifiers, submission time and actual observation. Keep authorized references to evidence rather than unnecessarily copying confidential records. Preserve the original request separately from any later correction; otherwise, a reviewer cannot tell whether another attempt means the same work.

Microsoft's Idempotent Consumer pattern distinguishes a stable key for one logical operation from a correlation identifier linking related messages. The latter can connect a request and its replies without identifying one change for duplicate handling. A supplier identifier alone likewise does not explain which proposed change is being repeated. Ask the technical owner which identifier the receiving service actually recognizes, where its protection applies and what its documentation promises. Calling a request idempotent describes repeated effects within a defined scope. It does not establish end-to-end execution exactly once, business correctness or a universal rule based on the request method.

The Idempotent Consumer worked example uses Service Bus messages and Azure Cosmos DB order records. When an identifier already exists, the consumer compares a stored request hash, a compact representation of content, or immutable business fields. Matching content is treated as a duplicate. Different content under the same identifier is routed for attention rather than silently discarded. That is a specific messaging/database example, not a supplier API's promised response. For a proposed supplier change, ask how the actual interface distinguishes an unchanged resubmission from a corrected request. Neither keeping an old identifier nor creating a new one resolves the original uncertainty by itself. Retention belongs in the same record. Microsoft warns that deleting duplicate-handling records too early permits late duplicates, including work operators resubmit after ordinary redelivery ends. Ask for the documented retention window and whether it still covers this operation. These sources supply no universal key lifetime; an identifier written in a log is not proof that the receiver still recognizes it.

Microsoft's Asynchronous Request-Reply pattern separates acceptance, status and eventual result. It proposes returning an existing status resource for a duplicate idempotency key instead of adding another work item. Ask whether the actual interface supports that design and how an authorized caller can recover the original operation when its acceptance response was lost. Do not assume every endpoint offers lookup by key. Read status according to the documented interface. The guidance describes implementations that return 404 before a target resource exists, which can be confused with an invalid identifier. It separately recommends a retention policy for status and results. Ask what expiry means; do not assume it produces a particular code or proves non-execution. The consumer pattern also describes external actions that cannot join a local database transaction. An in-progress marker can represent partial work or another consumer still working. Microsoft calls for reconciliation or intervention for unresolved records. Local duplicate protection does not automatically protect downstream services.

We propose one handoff joining operation identity and content, documented duplicate-handling scope and retention, supported status evidence, unresolved external work and the named decision owner. Technical owners explain what the evidence supports; the business owner authorizes the next action. Permission for the original change is not evidence of its outcome. For an authorized evaluation, ask how the team would handle matching content, changed content under the same identifier, unavailable status and evidence beyond its retention window. These are our suggested review cases, not vendor-mandated procedures or tests performed here. No retry count or delay follows from them. Where supported evidence establishes completion, record it without another modification merely for confirmation. Where the applicable contract supports another attempt, document its conditions before authorization. Where reconciliation is unsupported or inconclusive, have the owner explicitly authorize a hold and assign follow-up. Do not turn a missing response into permission to repeat the change.