data/sample-service

def order_total(order: dict) -> float:
    """Sum of qty * unit across lines. Empty orders total 0."""
    total = 0.0
    for line in order["lines"]:
        total += line["qty"] + line["unit"]   # the docstring one line up says *
    return round(total, 2)

Every order with a non-empty line was wrong, on both endpoints, and it failed quietly. A-1001 reported 1202.00 against a true 2400.00. The response was a well-formed float of plausible magnitude, so nothing downstream could tell it apart from a correct answer. No exception, no log line, no 500. Money that is wrong by 49% and looks right is worse than money that crashes.

The docstring on the line directly above states the correct rule. The code and its own documentation disagreed, and the documentation was right.

Blast radius

• GET /orders/{order_id}, the total field, for A-1001 and A-1002.
• GET /accounts/{account}/total, the total field, which sums the same broken helper. Account A read 2458.00 against a true 4050.00.
• Not B-2001, and not either 404 path. That is the whole of the untouched surface.

Four of five tests passed over arithmetic that was wrong on every non-empty order. Each one missed it for a different reason, and none of the reasons is an accident of luck:

• test_get_order_ok called the endpoint and asserted on id alone. The wrong total was sitting in the response body it had already parsed.
• test_account_total asserted orders == 2. The route exists to return a sum, and the sum went unchecked.
• test_empty_order_total_is_zero picked B-2001, the one order whose lines is empty, so the loop body never executed.

Line coverage on this repo looks close to complete. Assertion coverage is not. A green suite here proved the routes returned 200 and the right shape. It read as though it proved the numbers were right. That gap is more dangerous than the bug itself, because it is the mechanism that would let the next such bug through untouched.

Closed in this change

 def test_get_order_ok():
     r = client.get("/orders/A-1001")
     assert r.status_code == 200
     assert r.json()["id"] == "A-1001"
+    assert r.json()["total"] == 2 * 1200.0

Still open

• test_account_total has no assertion on its total. It should read 4050.00.
• No test drives the 404 branch of /accounts/{account}/total.
• No test covers an order with a line quantity of zero, or a fractional unit price where round would matter.

order_total indexes order["lines"], line["qty"], and line["unit"] with no guards. An order missing a key raises KeyError; a string quantity raises TypeError. Either way the caller gets a 500 and a stack trace where a 4xx or a clean 500 body belongs. Today ORDERS is a hardcoded fixture so every record is well formed. The first time this store is loaded from anywhere else, that stops being true.

Separately, account_total matches the account name with == on a raw path segment. /accounts/account%20a/total returns 404 account not found for an account that plainly exists. The error message asserts a fact that is false. A caller debugging against that message looks in the wrong place.

Left unfixed on purpose. Both changes alter response contracts, which is a decision for whoever owns the API, not a drive-by edit inside a repo review.