Pull request review with ranked findings

Get a prioritized code review that separates real defects from style nits, with a concrete fix for each issue.

Change note: Initial version

Prompt

Review the following {{language}} change as a careful senior engineer who will be on call for it.

Context: {{context}}
Review focus: {{focus}}

Diff or code:
{{diff}}

How to review:
- Read the whole change before commenting. Work out what it is trying to do, then check whether it does it.
- Only raise issues you can point to in the code. If something depends on code you cannot see, say what you would need to check instead of guessing.
- Skip formatting and naming nitpicks unless they hide a real problem.

Output format:
1. Verdict: approve, approve with changes, or request changes, in one sentence with the main reason.
2. Blocking issues: bugs, data loss, security holes, broken edge cases. For each give the location, why it fails (with a concrete input or scenario), and a suggested fix as a short code snippet.
3. Should fix: maintainability, missing tests, unclear error handling.
4. Optional suggestions: keep to at most three.
5. What is done well: one or two specifics.
6. Missing tests: list the cases you would add.

Variables

• {{language}}Languageselect

  Options: TypeScript, JavaScript, Python, Go, Java, C#, Rust, Ruby, PHP, Kotlin, Swift, C++

  Default: TypeScript

• {{context}}What the change doeslong

  Default: Adds retry logic to the payment webhook handler so duplicate events are ignored.

  One or two sentences of intent.

• {{focus}}Review focusselect

  Options: Correctness and edge cases, Security, Performance, Readability and maintainability, Test coverage

  Default: Correctness and edge cases

• {{diff}}Diff or codelongrequired

  Paste the diff or the changed files.

Example output

**Verdict:** Request changes. The idempotency check has a race that can still double-charge.

**Blocking issues**
1. `handleWebhook`, dedupe check: you read `processedEvents` and write it in two separate steps. Two deliveries of the same event arriving together both pass the read and both charge. Fix: make the insert the guard.
```ts
const inserted = await db.insertIfAbsent("processed_events", { id: event.id });
if (!inserted) return res.status(200).end();
```
2. Retry loop swallows the final error. After the last attempt the function returns normally, so the provider sees a 200 and never retries. Rethrow after the last attempt.

**Should fix**
- Retries use a fixed 100 ms delay; use exponential backoff with jitter or a retry storm will hit the payment API.
- Event id is logged together with the card fingerprint. Drop the fingerprint.

**Optional**
- Extract the retry loop into a small helper so it can be tested alone.

**Done well:** The handler is small and the signature check happens before any parsing.

**Missing tests:** duplicate event delivered concurrently; provider returns 500 on every attempt; malformed signature.

Notes

It forces a verdict first and ranks findings by severity, so the author sees what blocks the merge. Requiring a concrete failing scenario for each issue cuts speculative comments. Paste the surrounding files for deeper checks.