Describe one logical job before counting HTTP requests
The browser timeout creates a second HTTP request, but the customer asked for one logical result. Give that job a stable client-generated operation ID before the first submission. Log it beside every browser attempt, WordPress request, provider request, and stored output so retries can be grouped without guessing from prompt text.
Do not use a timestamp or random value generated inside each retry as the idempotency key; that guarantees the attempts look different. The key must remain stable for the same intended operation and change for a genuinely new user action. Define its retention window and user or tenant scope.
Run the 20-job fault matrix
Run 20 controlled jobs: five normal, five with a browser timeout before the response, five with a delayed WordPress handler, and five with an injected provider error. For each group, compare logical operations, browser submissions, REST request IDs, provider request IDs, and completed outputs.
Read the count signature
A 20:40:40 sequence means both REST attempts reached the provider. A 20:40:20 sequence means WordPress deduplicated successfully. A 20:20:40 sequence points to a server-side or provider-client retry. These ratios locate ownership more reliably than a generic 'retry storm' label.
| Metric | Target for 20 jobs | Failure signal | Owner |
|---|---|---|---|
| Browser submissions | 20 normally; retries explain extras | 40 after client timeout | JavaScript policy |
| Unique operation IDs | 20 | more or fewer than 20 | client identity contract |
| Provider requests | 20 | 40 | REST proxy or SDK retry |
| Committed outputs | 20 | duplicates or missing result | persistence layer |
Choose one deduplication owner
The WordPress boundary is usually the first trusted layer that can authenticate the caller, persist state, and prevent two provider calls. On first receipt, atomically claim the operation ID and record processing. A duplicate should return the in-progress status or the previously committed result rather than call the provider again.
If the provider supports its own idempotency mechanism for the exact endpoint, pass the same operation identity as an additional safeguard, not as a substitute for local state. Do not claim provider deduplication without endpoint-specific documentation and a replay test.
Separate retries from timeouts during rollout
Keep the browser timeout, server timeout, and provider-client retry count unchanged during the first deduplication test. Changing all four controls can make the count improve without proving why. Once the 20-job acceptance ratio passes, tune latency behavior in a second release.
Handle failure states explicitly. A job that failed before any provider acceptance may be retried; a job with unknown upstream acceptance should be reconciled by request ID before replay; a completed job should be returned from stored state. Expire keys only after the longest credible retry window.
Sign off on counts, not impressions
The acceptance sheet passes when 20 operation IDs produce 20 provider request IDs and 20 committed outputs, with deliberate duplicates returning a stable status. It must also show that two intentional new jobs with identical text receive distinct operation IDs.
Archive the experiment inputs, injected delays, counts, duplicate responses, retention setting, and rollback command. The implementation guide can then point future developers to an explicit contract: a retry may repeat transport, but it must not repeat paid work.
Use the duplicate-submission acceptance sheet from “A REST proxy and JavaScript retry submit the same AI job twice” on a real first installation. Download AI Cost Circuit Breaker for free, begin in Monitoring, and move to enforcement only after the expected signals and rollback are verified.