Repo X-ray — sample-service
Architecture and health snapshot, read against the code and one local test run.
4 of 5 tests
test_total_two_lines — it is the deliberate bug, not a flake.Modules
| Module | Owns |
|---|---|
| app/main.py | The FastAPI app, the in-memory ORDERS store (3 orders), the order_total() helper, and both route handlers. Everything the service does lives in this one 35-line file. |
| app/__init__.py | Empty — package marker only. |
| tests/test_orders.py | 5 tests: 2 hit the endpoints through TestClient, 1 checks a missing-order 404, 2 call order_total() directly as a unit. |
No persistence, no config, no auth layer. Restarting the process resets every order.
Endpoints
| Route | Input | Returns |
|---|---|---|
| GET /orders/{order_id} | order_id stringe.g. A-1001 |
200 · order + total404 · order not found |
| GET /accounts/{account}/total | account stringe.g. Account A |
200 · {account, orders, total}404 · account not found |
Both total values come from the same helper at app/main.py:13, so both endpoints inherit its bug.
Test coverage grid
The red sits in one column: nothing asserts a total except the helper's own unit test. Delete that one test and the service ships wrong prices with a green suite.
Bug impact per order
| Order | Account | Lines | As shipped | After fix | Difference |
|---|
Every figure computed by running both formulas over the real ORDERS store in app/main.py:6-10. Order B-2001 has no lines, so it totals zero either way and hides the bug completely.
Mispricing severity
Derived as (correct − shipped) / correct, not a figure the service computes. It says what the money chart cannot: A-1001 loses almost exactly half its value, so it is the worse offender in relative terms.
Order composition
Same scale as the impact chart, so the two read together. GIS-STD carries 3,600.00 of the 4,050.00 correct total — this describes the sample data rather than the code.
Top 3 risks
app/main.py:17 — this is the deliberate bug in the sample.
order_total() does total += line["qty"] + line["unit"] where it should multiply. Both endpoints return this total, so every non-empty order is priced wrong. It is caught by test_total_two_lines (expects 1650.00, gets 1256.00), and it also silently corrupts order A-1001 — 1202.00 shipped against a correct 2400.00 — which no test checks at all.
tests/test_orders.py:7-10
test_get_order_ok asserts only that the order id comes back, never the total field. The endpoint-level bug on A-1001 is therefore invisible to the suite, and the single unit test on the helper is the only thing standing between this bug and production.
app/main.py:33
The suite covers the missing-order 404 through test_get_order_missing, but nothing hits an unknown account on /accounts/{account}/total. The branch reads correctly, but it has never actually run.
Proposed fix
def order_total(order: dict) -> float: total = 0.0 for line in order["lines"]:- total += line["qty"] + line["unit"]+ total += line["qty"] * line["unit"] return round(total, 2)
Applying this turns the failing test green and moves Account A from 2,458.00 to 4,050.00. It does not close risks #2 or #3 — those need new tests.
Order line calculator
Enter a quantity and unit price to see the shipped total against the fixed one.