Honor Retry-After without creating an unbounded replay
The local receiver responds 429 with Retry-After, but the runner retries immediately. Add bounded backoff with a fake clock and explicit terminal reasons.
- Focused work estimate
- 1h 45m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Retry policies · Rate limits · Time-based testing
Estimated field mix
- Quality engineering50%
- Integrations30%
- Networking20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
An integration team closes incidents with screenshots of provider dashboards, then struggles to reproduce the same delivery sequence. Build a synthetic event corpus and replay runner against an allowlisted local receiver.
Setup prerequisites
- Create a local receiver fixture with an inspectable event store.
- Use generated test signing keys and synthetic payloads only.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- REPLAY-101 · Define a portable synthetic webhook fixture
- REPLAY-102 · Generate signatures from raw bytes and an injected clock
- REPLAY-103 · Assert duplicate delivery produces one business effect
- REPLAY-104 · Deliver update-before-create with a reproducible schedule
- REPLAY-106 · Reproduce a receiver commit followed by a dropped response
- REPLAY-107 · Block replay targets outside the approved local receiver
Acceptance criteria
- Supported Retry-After forms are parsed and capped by the run time budget.
- Malformed or negative values fall back to documented bounded backoff.
- Maximum attempts and overall deadline stop retries with a terminal reason in the report.
Implementation constraints
- Seed jitter or disable it for deterministic fixtures.
Verification to include
- Advance a fake clock through 429, 503, and success and assert scheduled retry times.
- Return an excessive delay and confirm the deadline ends the run without waiting in real time.
Deliverables
- Retry policy and fake-clock timing cases
Rollout and recovery
Apply bounded retry policy to all replay scenarios; allow zero retries for transport debugging.
Value of the work
For the engineer: Practice protocol verification, controlled fault injection, and reproducible incident investigation.
For the team: Review concrete evidence that webhook consumers tolerate real delivery failure patterns.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.