Developer staffing guide · 8 minute read ·
Test idempotency keys after their retention window closes
Check duplicate requests just before and after a server forgets a key.
Readiness check
Is the handoff ready?
Use this table before you send the first ticket. Fix the weak spots while access is still limited.
| Area | Ready | Needs work |
|---|---|---|
| Question | One observable idempotency-key retention outcome | A request to inspect the whole system |
| Fixture | a sandbox endpoint with inert transactions and fixed request bodies | Customer data or shared credentials |
| Evidence | key hash, request hash, response, retry time, resource ID, and expiry rule | A pass label without observed values |
| Approval | The API owner approves retention, conflict behavior, and production changes. | The contractor changes production alone |
Reproduce the idempotency-key retention failure safely
A late retry can create a second resource after the original key expires. Start with one case that can fail without touching customer records or production infrastructure. Write the expected result, stop condition, and reviewer beside the fixture.
Use a sandbox endpoint with inert transactions and fixed request bodies. Label every identity and artifact so a reviewer can distinguish test evidence from a live record.
Leave enough evidence for a second person
Capture key hash, request hash, response, retry time, resource ID, and expiry rule. Include the source revision and test time. If behavior changes between runs, retain both results.
The API owner approves retention, conflict behavior, and production changes. A remote programmer can prepare the fixture, run bounded checks, and explain the result. New policy, privileged access, and release approval stay with the named owner.
Copy-ready brief
Paste this into your hiring request
Test one bounded idempotency-key retention case against written acceptance rules.
a sandbox endpoint with inert transactions and fixed request bodies
Record key hash, request hash, response, retry time, resource ID, and expiry rule.
The API owner approves retention, conflict behavior, and production changes.
Buyer questions
Questions about planning the role
What should the first run prove?
It should show the expected idempotency-key retention result for one controlled fixture.
What belongs in the handoff?
Include key hash, request hash, response, retry time, resource ID, and expiry rule, the source revision, and any untested condition.
Who approves a production change?
The API owner approves retention, conflict behavior, and production changes.
Sources
Planning references
These links explain the security, code review, and worker classification points used in this guide.
- NIST Secure Software Development FrameworkNIST guidance for managing software development risk.
- GitHub pull request reviewsFirst-party documentation for review and approval.