Order-processing worker — are you ready to merge?

You said you only skimmed this diff. Below is what it actually changes, grouped by risk — and then six questions. The decision being extracted is honest: merge now, or re-read two sections first.

Read the report, then answer the quiz. A wrong answer shows you exactly which section you skimmed. Your reply — pass, or the list of sections to re-read — assembles itself at the bottom. Copy it and paste it back into the chat.

What is this?

A live example from the finding-unknowns skill. Before a risky merge, the cheapest unknown to surface is what you don't know about your own change. The report is grouped by risk rather than by file, and the quiz checks whether the risky parts actually made it into your head.

High risk · in-flight workers vs the column rename

Migration 007 renames orders.status to state under running workers

Deployed workers poll SELECT id FROM orders WHERE status = 'pending' every five seconds. The moment the rename applies, that query starts failing with "column does not exist" — on every instance, until the new code is deployed. Order processing stalls; nothing crashes loudly.

Neither deploy order fixes this alone: old code breaks after the migration, new code breaks before it. The safe path is a compatibility step — deploy code that tolerates both column names (or a temporary view), migrate, then clean up.

High risk · retry semantics changed twice in one diff

4xx responses are now final; everything else retries more

The old code retried every provider error up to 3 attempts. The new code throws immediately on any 4xx — a declined card fails on the first try, permanently — while 5xx and network errors now retry up to 5 attempts with exponential backoff. Both changes are deliberate, but they ship together silently: dashboards tuned to "3 attempts for everything" will misread both failure modes.

Medium risk · the new "charging" state

An idempotency claim, with no reaper

Workers now set state = 'charging' before calling the payment provider, so a parallel instance skips the row instead of double-charging. But if a worker dies mid-call, the row stays in charging forever — this diff adds no timeout or reaper. Rare, manual to fix, worth a follow-up ticket before it happens at 3am.

Low risk · housekeeping

The index moves with the rename (idx_orders_status → idx_orders_state), so polling stays indexed. The state comment gains the new charging value. Nothing else touches the schema.

The quiz — six questions, then your verdict

1 · Migration 007 applies while the current workers are still running. What happens to them?

The workers still query status, which no longer exists — every poll errors and processing stalls quietly. See the column rename section.

2 · The payment provider returns HTTP 402 for an order. What does the new code do?

4xx is now treated as final. Only 5xx and network errors retry. See the retry section.

3 · Same order, but the provider returns HTTP 503. What does the new code do?

Server errors got more patient in the same diff that made client errors final: MAX_ATTEMPTS went from 3 to 5. See the retry section.

4 · What is the new charging state actually for?

A worker claims the row before calling the provider so another instance can't double-charge it. See the charging-state section.

5 · A worker sets charging, calls the provider, and dies before the response. Where does that order end up?

The diff adds the claim but no reaper — nothing ever moves a row out of charging except a successful response. See the charging-state section.

6 · What's the safe rollout order for this change?

Old code reads status, new code reads state — each breaks on the other's schema. You need a step that tolerates both. See the column rename section.

Your verdict — written for you

Copied — paste it back into the chat