---
title: "A Retry Key Has a Scope: Count the Requests and the Effects Separately"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/api-idempotency-key-scope-request-effects"
last-updated: "2026-10-20"
---

# A Retry Key Has a Scope: Count the Requests and the Effects Separately

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

A retry key supplies duplicate protection under the service's declared operation, parameter and scope rules. Reusing its text does not establish one global operation. Count network attempts, accepted scoped operation identities and resulting resource effects separately, then compare that contract with the application's actual requirement when a reply is lost or the destination changes.

## Name the effect before counting repeated requests

An application may want one allocation while making several attempts to obtain it. An attempt is one submitted request. The logical operation is the application's intended change. A provider's scoped operation identity is the unit within which it recognizes repetitions. The resource effect is the change that actually results. Those quantities need their own names because the application's idea of sameness can be broader than the provider's.

RFC 9110, published in June 2022, defines idempotency through the intended server effect of repeating an identical request. It allows separate logging and other incidental effects, and replies can differ. Idempotency therefore establishes neither single delivery nor identical response bytes.

Also define the resource unit. The AllocateHosts API describes Quantity as the number of Dedicated Hosts to allocate. One accepted operation can intentionally create several resources. To reason about one allocation effect in the example below, we explicitly stipulate a request for one.

References: [H1](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2), [A2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AllocateHosts.html)

## Read EC2's named operation and geographic rules

EC2 documentation checked October 20, 2026 distinguishes default idempotency from actions supporting a client token. For a successful token-based request, repeating the token and parameters adds no further action. Changing parameters other than Region or Availability Zone produces IdempotentParameterMismatch.

Geography changes equivalence. AWS describes regional and zonal scopes, with AllocateHosts as a zonal example: the same token can succeed in different Availability Zones within one Region.

RunInstances supports both scopes. Explicit zone selection, or implicit selection through SubnetId, makes it zonal; selecting neither makes it regional. A different applicable zone or Region can therefore permit another launch. These are EC2 rules; an inference API needs its own documented contract.

The AllocateHosts and RunInstances API references identify ClientToken as case-sensitive. An offer saying only that it accepts a request identifier leaves unanswered which identifiers actually participate in duplicate suppression.

References: [A1](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html), [A2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AllocateHosts.html), [A3](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)

## IR-251: five attempts produce two allocation effects

Original fictional case IR-251 uses a stipulated EC2-style zonal contract for a request to allocate one resource. K is a symbolic key, P is the unchanged set of other relevant parameters, and Z1 and Z2 are different zones in the same Region. All attempts occur while the service still recognizes K. These are invented states, not observations of an AWS account or a Leviathan test.

Attempt 1 sends K and P to Z1. Stipulate that it succeeds internally and creates one allocation, but its reply is lost. Attempts 2 and 3 repeat K and P in Z1. Under the stipulated rule, they add no allocation. The totals are three attempts, one accepted scoped operation identity and one allocation effect.

Attempt 4 uses K with the same other parameters in Z2. Only the zone changes, and success there is separately stipulated. Z2 is a different duplicate-suppression scope, so this request adds one allocation. The totals become four attempts, two accepted scoped identities and two allocation effects. The repeated text K has not created a global one-allocation guarantee.

Attempt 5 returns to Z1 with K but changes a parameter outside the allowed geographic exceptions. Apply the documented mismatch behavior: it fails with IdempotentParameterMismatch and adds no allocation. The final totals are five attempts, two accepted scoped identities and two allocation effects: 1 + 0 + 0 + 1 + 0 = 2 effects.

The conflicting fifth request is a rejected attempt to change the description associated with the existing scoped token. It supplies no third accepted operation and does not revise the first allocation. No resource removal is stipulated. The final count is cumulative allocation effects under this example's conditions, with no inference about price, resource capability or available capacity.

References: [A1](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html)

## A lost reply and duplicate protection answer different questions

After attempt 1, the caller lacks its reply while the example stipulates that the allocation exists. That is an information gap at the caller. Duplicate suppression supplies a rule about the effect of an equivalent repetition. It does not make the missing reply appear or establish every intermediate state visible to the caller.

For a real offer, distinguish the documented rule from the evidence identifying the resulting resource. A provider can explain that equivalent repetition avoids an additional allocation while the application still needs a supported way to determine the status of its requested operation. Neither answer substitutes for the other.

The related deadline and cancellation guide addresses the caller's wait and evidence that server work stopped. The streaming guide addresses initial output, message termination and accepted answers. Their missing-completion questions remain relevant; IR-251 adds the separate question of which attempts the provider treats as equivalent.

## Compare the contract with the application's relocation requirement

Suppose the application requirement is one allocation anywhere across Z1 and Z2. IR-251 fails that requirement after attempt 4 even though each stipulated zonal rule has been honored. If the requirement instead calls for one allocation in each zone, those same two effects can match the requested count. The useful judgment depends on the application's intended result, not the number of times K appears in a record.

Ask an offer to identify the API operation and version, the field that controls duplicate recognition, the compared parameters and the geographic boundary. Identify whether the application's proposed destination change stays within that boundary. A move can be a new effect under the provider's rules even when the application describes it as continuing one task.

Then ask how long recognition lasts and what happens to a later request after that period. A token observed in an old record is not evidence that the service still recognizes it. This article assigns no retention duration to EC2; the selected service needs applicable evidence for the application's actual interval.

Read the offer's evidence using separate attempt identifiers and resulting resource identifiers, preserving the scope and relevant parameter set. A common token alone cannot reconcile the effects. Ask the appointed platform owner to account for a lost reply, an equivalent repetition, a destination change and a conflicting parameter under the actual contract. This is a comparison of promised behavior and supporting evidence, not an instruction to perform those operations.

RFC 9110 also conditions automatic repetition of non-idempotent methods on knowledge of idempotent semantics or that the original was never applied. A key's presence alone supplies no blanket retry permission. An allocation rule likewise supplies no total bill or guarantee that surrounding email, database or tool actions happen exactly once; those effects need their own contracts.

References: [H1](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2)

## Connect a resulting equipment project to physical deployment

If the infrastructure choice also creates a physical equipment project, Leviathan's Complete Physical Infrastructure Deployment service can discuss agreed receiving, rack integration, onsite installation, IT cabling and physical handoff records. Bring the equipment, destination, required connections and requested stages to the related service and project inquiry.

Cloud administration, retry automation, serving integration and application operation belong with separately appointed providers. A physical installation scope supplies no API duplicate-suppression control or procurement guarantee.

References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment)

## Primary sources

- [H1 — RFC 9110 — HTTP Semantics, section 9.2.2: Idempotent Methods](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2). Checked 2026-10-20. June 2022 HTTP semantics distinguish intended effects, incidental actions, differing replies and conditional automatic retries.
- [A1 — AWS — Ensuring idempotency in Amazon EC2 API requests](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html). Checked 2026-10-20. Defines EC2 token, parameter-mismatch and geographic scope rules; supports IR-251's stipulated contract.
- [A2 — AWS — AllocateHosts API reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AllocateHosts.html). Checked 2026-10-20. Defines allocation quantity and ClientToken for the named Dedicated Host operation.
- [A3 — AWS — RunInstances API reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html). Checked 2026-10-20. Identifies ClientToken as the case-sensitive idempotency field for this separate launch operation.
- [L1 — Leviathan Systems — Complete Physical Infrastructure Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Describes the physical equipment delivery package and inquiry; included tasks and availability are engagement-specific.

## Related Leviathan resources

- [Caller deadlines, cancellation and evidence that server work stopped](/articles/inference-request-queues-deadlines-and-cancellation)
- [Streamed output, message termination and accepted answers](/articles/inference-stream-deltas-versus-completed-response)
- [Cross-Region model routing and application continuity](/articles/cross-region-inference-profile-versus-application-failover)
- [GPU cloud quotas, capacity allocations and usable windows](/articles/gpu-cloud-capacity-availability)
- [Complete Physical Infrastructure Deployment](/services/turnkey-gpu-deployment)
- [Discuss equipment, destination and physical installation scope](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fapi-idempotency-key-scope-request-effects)

## Does the infrastructure decision include physical installation?

Share a nonconfidential outline of the equipment, site, required IT connections and physical handoff to discuss scope, requirements and availability.

[Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/api-idempotency-key-scope-request-effects)