Sample PR Audit
Purpose: demonstrate report structure, evidence level, prioritization, and review tone. This is not a review of a real repository.
Executive summary
The hypothetical PR adds retry handling to an outbound notification worker. The current implementation can deliver the same notification twice after a timeout because the retry path does not preserve a stable idempotency key. Recommendation: REQUEST CHANGES.
Verified context
- Repository / PR: fictional acme-notify #214
- Target branch: main
- Review scope: retry policy, request construction, tests, deploy risk
- Limitations: no production telemetry or provider contract available
Blocking finding
| Severity | Evidence | Impact | Smallest safe fix |
|---|---|---|---|
| High | The first attempt and retry create a new provider request without reusing a stable idempotency key. A timeout does not prove the provider rejected the first request. | A successful first request followed by a client-side timeout can produce a duplicate customer notification. | Generate one stable operation key before the first send and reuse it across all attempts. Add a test for "provider accepts, client times out, retry occurs." |
Test assessment
The fictional tests cover immediate success and explicit provider failure, but not the ambiguous timeout case that creates the blocking risk.
Delivery notes
- No schema migration.
- Rollout risk is concentrated in duplicate side effects.
- Monitor retry count and idempotency rejection rate after deployment.
- Rollback is straightforward if no persistent state format changes are introduced.
Confidence
High for the duplicate-delivery risk given the stated fictional request behavior.