Zero records written, exit code 0

Three separate mechanisms combine.

1. except: pass around parsing swallows every error, including KeyError for the missing timestamp. The record is dropped without a log line, and the caller never learns it failed. A bare except also catches KeyboardInterrupt and SystemExit, so the parse loop cannot even be interrupted cleanly. That accounts for the missing row.
2. except Exception around the call retries the 400. A 400 means the request is wrong and will be wrong on attempt 2 and 3; retrying it three times with no backoff burns time and produces the same error, then raises. If the caller of the wrapper catches broadly or if the whole import is inside a similar block, the run continues with an empty result.
3. The 503 is retried three times with 1-second sleeps, i.e. the wrapper waits about 2 seconds in total against a 20-second outage. All three attempts fail, the record set is empty, and the loop finishes normally. Nothing in the code distinguishes 'finished with 0' from 'succeeded with 0'.

The exit code is 0 because nothing raised to the top level; the process has no concept of partial failure. Logging the exception at the point it is caught, and returning a result object rather than an empty list, would have made the run visible without changing the retry behaviour at all.

Retry only when the failure is plausibly transient on the next attempt.

Retry: connection errors, timeouts, 429, 500, 502, 503, 504. Use exponential backoff with jitter (e.g. 1s, 2s, 4s, capped, ±20% jitter so a fleet of workers does not synchronise), a maximum of about 5 attempts, and honour Retry-After when present. Against a 20-second outage, a policy that waits about 2 seconds is functionally a no-retry policy.

Do not retry: 400, 401, 403, 404, 409, 422. These are deterministic; retrying just triples the load and delays the alert. Classify on the exception type or status code, never on Exception.

Duplicate writes: retrying a POST is not automatically safe. If the request may have reached the server before the timeout, a retry can create a second record. Use an idempotency key per record generated before the first attempt, or make the write an upsert keyed on a natural ID, so attempt 2 is a no-op. Without that, a 503 retry during the blip can double-write the records that did succeed.

Also make the outcome loud: a run that writes fewer records than it fetched must exit non-zero and emit a count plus the failing IDs.

assert import_records(fixture) only checks that the return value is truthy. An empty list is falsy, so it catches the total-empty case but not the partial case, and it says nothing about which records were written or how errors were handled.

Replace it with assertions on content and failure behaviour:

1. Exact output: assert [r['id'] for r in result.records] == [1, 2, 3] and assert result.dropped == []. Catches the silent drop of the missing-timestamp record only if the fixture includes one, so build a fixture with a missing timestamp and assert the record is reported as rejected with a reason, not silently gone.
2. Error propagation: make the fake client raise a KeyError during parsing and assert the run reports a failure rather than returning 0 records with no message. This is the test that fails today.
3. Retry classification: fake client returns 400 → assert exactly one call. Returns 503 twice then 200 → assert three calls and one record. The second is the test that would have exposed the 2-second-versus-20-second gap.
4. Idempotency: simulate a timeout after the server accepted the write, retry, and assert the warehouse has one row.

Speed: do not call time.sleep. Inject the sleep/clock, or use a fake clock, so retry tests run in milliseconds; otherwise the tests that protect the money path are the first ones people skip.