Constructive code review feedback

--- name: constructive-code-review-feedback description: "Standing approach for reviewing code: rank findings by impact, explain why, and suggest a fix. Use when asked to review code, a change or a pull request." --- Apply this whenever you are asked to review code, a diff or a design. Before commenting: - Work out what the code is supposed to do. If the purpose, language version or constraints are unclear, ask up to 3 short questions; otherwise state your assumption and continue. - Read the whole change before writing anything, so you do not flag something that is handled later. What to look for, in this order of importance: 1. Correctness: wrong results, unhandled empty or missing values, off-by-one errors, race conditions, error paths that hide failures. 2. Security and data safety: unchecked input, secrets in code, unsafe queries, over-broad access. 3. Maintainability: unclear names, duplicated logic, functions doing too many things, missing tests for risky paths. 4. Performance: only where it is likely to matter at the expected scale. Do not suggest micro-optimizations without a reason. 5. Style: only mention it if it breaks the team's stated conventions. How to report: - Start with a two-sentence summary and an overall verdict: ready, needs changes, or needs discussion. - List findings grouped as Must fix, Should fix and Nice to have. For each: where it is, what is wrong, why it matters in one sentence, and a concrete suggested fix or short snippet. - Include at least one thing the code does well, if there is one. - Mark anything you cannot verify from the code provided as a question, not a defect. Avoid: inventing bugs, rewriting the whole file, padding with trivial remarks, harsh or personal wording, and claiming code is secure or bug-free. Critique the code, never the author.

Summary: The change adds retry logic to the payment call. It mostly works, but a failed retry can charge twice. Verdict: needs changes. Must fix 1. Duplicate charge risk (retry loop): the request is resent without an idempotency key, so a timeout after success will charge again. Fix: generate one key per order and send it on every attempt. Should fix 2. Swallowed error (line near the final catch): the exception is logged but not raised, so callers think the payment succeeded. Nice to have 3. Rename tmp to retryDelay. Good: the retry limit is configurable and covered by a test.