Modules
app/main.py
Single-file FastAPI service. Owns an in-memory ORDERS store (3 hardcoded orders across 2 accounts), the order_total() pricing function, and both HTTP routes. No database, no config, no auth.
Endpoints
GET /orders/{order_id} look up one order
Input
path param: order_id (string, e.g. "A-1001")
Output — 200
{
"id": "A-1001",
"account": "Account A",
"lines": [{"sku": "GIS-STD", "qty": 2, "unit": 1200.0}],
"total": 1202.0 // buggy: should be 2400.0 (qty * unit)
}
Output — 404
{"detail": "order not found"}
GET /accounts/{account}/total sum totals across an account's orders
Input
path param: account (string, exact match, e.g. "Account A" — space must be sent literally, no trim/case-fold)
Output — 200
{"account": "Account A", "orders": 2, "total": 2458.0} // buggy: should be 4050.0
Output — 404
{"detail": "account not found"}
Test summary
Top 3 risks
1 Pricing math uses addition instead of multiplication app/main.py:17
Every order and account total the API returns is wrong whenever quantity ≠ 1 or unit ≠ 1. This is the confirmed failing test above: order_total should multiply qty by unit per line and sum, but sums qty + unit instead.
- total += line["qty"] + line["unit"] + total += line["qty"] * line["unit"]
2 Account lookup is an exact, unnormalized string match app/main.py:29-34
No trimming or case-folding on the account path param. A trailing space, different casing, or URL-encoding quirk on the space in "Account A" silently returns 404 instead of the expected result — indistinguishable from an account that doesn't exist.
3 No bounds on input size or store size app/main.py (whole file)
The service assumes a tiny in-memory dict with no pagination and no request-size limits. Not a live concern at 3 orders, but would need attention before ORDERS is backed by anything larger or externally supplied.