Repo X-ray — sample-service

Architecture and health snapshot, read against the code and one local test run.

2 endpoints 4 / 5 tests passing 1 confirmed bug
Test health
80% of the suite passes
4 of 5 tests
Passed 4 Failed 1
The one failure is test_total_two_lines — it is the deliberate bug, not a flake.
3
Modules
1 holds all logic
2
Endpoints
both GET, both public
1 / 3
Critical risks
3 found in total
1,592.00
Mispriced on Account A
ships 2,458 vs 4,050

Modules

3 files · 64 lines
ModuleOwns
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

read from handlers, not the README
RouteInputReturns
GET /orders/{order_id} order_id string
e.g. A-1001
200 · order + total
404 · order not found
GET /accounts/{account}/total account string
e.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

9 cells · 3 gaps
Happy path Error path Value correctness GET /orders/{order_id} testedtest_get_order_ok testedtest_get_order_missing not assertedonly id is checked GET /accounts/{account}/total testedtest_account_total not tested404 branch never runs not assertedonly the order count order_total() helper testedtest_total_two_lines n/ano error branch assertedand this is what fails

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

Total as shipped Total after the fix

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

share of the correct price lost

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

correct value by sku
GIS-STD MA-PRO

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

ranked, with file and line

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

risk #1 · one line
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

both formulas, side by side

Enter a quantity and unit price to see the shipped total against the fixed one.

Enter values above and click Compute.