data/sample-service: where the bodies are

app/main.py:17 added the line quantity to the unit price instead of multiplying them. It now multiplies, which is what the docstring on line 14 always said. It was never contained: both endpoints compute money through this one helper, so the wrong number reached the order response and the account rollup, and nothing in either response signalled it. Kept here as the record of what it cost while it was live.

total += line["qty"] * line["unit"]

A-1001   2 x 1200.00                = 2400.00 truth, API says 2400.00   (match)
A-1002   10 x 45.00 + 1 x 1200.00   = 1650.00 truth, API says 1650.00   (match)
Account A rollup                    = 4050.00 truth, API says 4050.00   (match)

app/main.py:16-17 reaches into order["lines"], line["qty"] and line["unit"] with raw indexing. Nothing validates the store: no Pydantic model on the way in, no response model on the way out. A row missing a key raises KeyError out of the handler, which FastAPI turns into an unhandled 500 with no useful body. Today the store is a literal, so it holds. Reading a real database or feed, the reach depends on the missing key: a bad qty or unit breaks the orders that contain it and any account rollup that touches them, while a missing account key breaks the scan at app/main.py:31 for every account. A 500 is the honest status for corrupt server-side data; the defect is that it is unhandled and unlogged, so nobody learns which row did it.

order_total({"lines":[{"sku":"X","qty":1}]})    ->  KeyError: 'unit'
order_total({"id":"X"})                         ->  KeyError: 'lines'
order_total({"lines":[{"qty":"2","unit":10.0}]}) ->  TypeError: can only concatenate str
order_total({"lines":[{"qty":2,"unit":None}]})   ->  TypeError: unsupported operand type

A missing key is not the only shape. A key present with the wrong type raises TypeError from the same line, so the guard has to validate types, not just key presence. The two TypeError messages above are from the old +; the fix changes the wording, not the failure.

app/main.py:31 filters the entire store on exact string equality, with the account name arriving as free text in the path. Three consequences. Matching is case-sensitive and untrimmed, verified below, and nothing in the code or tests states whether that is intended, so the identity rule is undefined rather than merely strict. There is no account registry: an account exists only as a string on an order, so the 404 at app/main.py:33 is the only possible answer for a name with no orders, and the endpoint cannot distinguish a typo from a real but empty account. And the scan is O(n) per request over the whole store, which is free at 3 orders and not free once the store is a table.

GET /accounts/Account A/total  ->  200  {"account":"Account A","orders":2,...}
GET /accounts/account a/total  ->  404  {"detail":"account not found"}