---
title: "Verify rate-limit recovery keeps the original operation"
description: "Test an externally prepared sandbox rate-limit response, checking clear retry guidance, unchanged form data, and one eventual accepted operation."
canonical_url: "https://vostride.com/agent-library/network-recovery/rate-limit-retry-state.md"
md_url: "https://vostride.com/agent-library/network-recovery/rate-limit-retry-state.md"
content_kind: "recipe"
topic: "network-recovery"
---

# Verify rate-limit recovery keeps the original operation

Test an externally prepared sandbox rate-limit response, checking clear retry guidance, unchanged form data, and one eventual accepted operation.

## Risk

A retry banner can hide repeated automatic submissions or discard the original payload. Verify the server-enforced retry window through the external fixture and evaluate both rejected attempts and the eventual accepted result.

## Fixtures

- An owned sandbox form for creating non-delivering announcement drafts and a test account with no publish permission.
- An external response fixture returning a documented rate-limit response with a known retry window before allowing one create request.
- A request ledger and draft oracle recording attempted payload hashes, accepted identifiers, and fixture time; clock control is external if accelerated.

## Steps

1. Fill the announcement title and body with unique fixture text, submit, and verify the app explains temporary throttling while retaining both fields.
2. Before the externally recorded retry window ends, verify the app does not show a created draft or misleading successful completion.
3. After the fixture reports the retry window elapsed, use the documented retry control and verify the accepted draft detail appears.
4. Reopen the draft and verify its complete title and body match the original submission rather than an empty retry payload.
5. Inspect the independent request ledger and verify the accepted request retained the original payload identity and created one draft; compare earlier attempts with the product backoff contract.

## Expected results

- The initial rate-limited request creates no draft in persistent state.
- The eventual accepted request uses the original intended content.
- Observed request timing and count comply with the product retry policy established before execution.

## False-pass traps

- Waiting an arbitrary short delay does not establish that the server retry window elapsed.
- A success toast from another action can hide a dropped or empty retried payload.

## Cleanup

- Delete the announcement draft and restore the external rate-limit fixture to its normal response policy.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa first test](/docs/agent-qa/guides/first-test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)

- [Network recovery QA recipes](/agent-library/network-recovery.md)
- [Software factory QA library](/agent-library.md)