The proposal looks complete
An assistant produces this handler. Do not run it against a real service. Read it as a review exercise:
async function proposedSubmit() {
const total = Number(document.querySelector('#total').textContent);
try {
await fetch('/api/orders', {
method: 'POST',
body: JSON.stringify({ total, requestId: crypto.randomUUID() })
});
document.querySelector('#status').innerHTML = 'Confirmed';
} catch {
return proposedSubmit();
}
}
Before asking for a rewrite, explain the contract it would have to satisfy. Our course service does not even expose /api/orders; it exposes a named fixture confirmation endpoint and requires an expected revision.
Review in layers
The displayed total is formatted output, not authoritative input. Fetch can resolve on an HTTP failure. A new key per retry destroys request identity. Unbounded recursion retries permanent failures. There is no unknown-outcome state, no revision handling, no frozen snapshot and no control over repeated clicks. The response is neither parsed nor validated.
The constant innerHTML assignment shown here is not itself an injection of untrusted text. However, use textContent for a text message and do not extend this pattern to customer-provided strings. A careful review distinguishes actual defects from generic warnings.
Ask for evidence, not confidence
Write a better request to the assistant: specify the real endpoint and request shape, same-key replay, 409 behavior, unknown outcome, and a deterministic test for response loss. Ask it to identify assumptions before producing an implementation.
Then inspect its patch. Can you explain every new dependency? Does the test assert the business result or merely call the handler? Does the code pass a changing draft object into a pending request? Does its documentation match the actual route?
Consult primary documentation for unfamiliar API semantics. Documentation can explain fetch behavior; it cannot decide whether your business should accept a stale order. That decision remains in the contract.
Independent review lab
Take one function from your own project and ask for a simplification. Before seeing the answer, write down the invariants its replacement must preserve. Compare the proposal with those invariants and run your counterexamples. Accept, modify or reject it with reasons.
Your deliverable is a short review containing the proposed change, at least two meaningful checks, the decision and any remaining uncertainty. Do not invent a successful test run or a business requirement to make the proposal look finished. A useful reviewer can explain why a convincing solution is wrong and what evidence would make it acceptable.