Repo X-ray
Two endpoints, five tests, one bug found by running them.
pytest run captured below (4 passed, 1 failed) plus direct probes of the running code with bad, empty, huge, and malformed input — nothing invented.ORDERS dict, one pricing function, two routes. No other modules, no persistence layer, no auth.TestClient: order lookup (found/missing), line-item totals (two lines, empty), and one account rollup.| Method | Path | Input | Output |
|---|---|---|---|
| GET | /orders/{order_id} | path param order_id (e.g. A-1001) | 200: order + computed total · 404 {"detail":"order not found"} if unknown |
| GET | /accounts/{account}/total | path param account (e.g. Account A) | 200: account, order count, summed total · 404 if no orders match |
assert order_total(ORDERS["A-1002"]) == 10 * 45.0 + 1 * 1200.0 AssertionError: assert 1256.0 == ((10 * 45.0) + (1 * 1200.0)) where 1256.0 = order_total(A-1002) # expected 1650.0
Every total returned by both endpoints is wrong. order_total() adds quantity and unit price instead of multiplying them, so the error compounds with scale — it is not a rounding issue, it is the wrong formula.
Proposed fix — the smallest change that fixes it, verified against the failing test:
order_total() reads line["qty"] and line["unit"] with no validation. Neither endpoint wraps the call, so any order whose line is missing a key throws an unhandled KeyError straight through FastAPI as an unhandled 500.
There is no schema validation on line items and no try/except at the call site — any bad upstream write (or a future write endpoint) takes the service down per request instead of failing one bad record cleanly.
The API models two separate accounts (Account A, Account B) but has no auth dependency anywhere. Both routes are open: any caller who can reach the service, or guess/enumerate an order id, can read another account's order lines and revenue.
Fine for a single-tenant lab demo; a real cross-tenant deployment needs a per-account auth check before this ships.
GET /orders/nope → clean 404, {"detail":"order not found"}. Handled correctly.B-2001 has zero lines → total: 0.0, no divide-by-zero or loop error. Handled correctly.KeyError rather than a 4xx. This is risk 02, reproduced directly against the code.Confirm the two numbers in the top risk yourself: run pytest -q in data/sample-service/ and check that test_total_two_lines is the one test that fails, with the same 1256.0-vs-1650.0 mismatch shown above. If that matches, the rest of this page traces to the same run.