A malformed routes.yaml silently wipes out every route

Nobody has started this yet — be first.

Business impact

POST /admin/routes/reload is the operational escape hatch for pushing route changes without a redeploy. If someone makes a typo in routes.yaml -- a bad indent, a field that fails a validator, a missing required key -- the reload endpoint does not fail loudly; it silently succeeds with an empty route table. Every route disappears, every proxied request starts 404ing, and the response the operator who ran the reload actually sees gives no indication anything went wrong. This turns a typo into a full outage that looks, from the caller's side, like a successful operation.

Problem

load_routes_file() wraps RouteTableFile.model_validate(raw) in a bare try/except Exception, logs a warning, and returns [] on any validation failure -- the exact same silent-empty-table behavior that is correctly (and intentionally) used for the missing-file case just above it, now also covering the completely different case of "the file exists but is broken."

Current behavior

A routes.yaml with an invalid route (e.g. a path_prefix that does not start with /, which RouteConfig's own validator already rejects) makes load_routes_file() return [] and log a warning, exactly as if the file did not exist at all -- the caller cannot tell "nothing configured yet" apart from "configured, and broken."

Expected behavior

A missing routes file still results in an empty table (the existing, correct, documented behavior for a fresh gateway). A file that exists but fails to parse or validate should raise, loudly, so POST /admin/routes/reload returns an error status instead of 200 with an empty list, and a broken file at startup should fail the process instead of silently booting into an empty, useless state.

Steps to reproduce

Write a routes.yaml with an invalid route (e.g. a path_prefix that does not start with /).
Call load_routes_file(path) directly, or POST /admin/routes/reload with settings.routes_file pointed at it.
Observe: [] / 200 with an empty table, and a merely-logged warning. Expected: an exception propagates (or, at the admin-endpoint layer, a 4xx/5xx response).

Why this matters

"Return an empty result and log a warning" is the right shape of behavior for the missing-file branch immediately above -- that is a genuinely benign, expected state. Reusing that shape for a validation failure conflates "there is nothing here" with "there is something here and it is broken," which are operationally opposite situations requiring opposite responses (one is fine to ignore, the other needs to block the operation and page someone).

Suggested approach

Look at what currently happens to the except Exception block's exception -- it is logged and discarded. Decide what load_routes_file should do instead, and check how app/admin/routes.py::reload_routes and app/main.py's startup path each currently call this function, so a fix here surfaces correctly at both call sites.

Acceptance criteria

load_routes_file() on a missing file still returns [] (no change to that branch)
load_routes_file() on a file that exists but fails validation raises instead of returning []
POST /admin/routes/reload against a broken file returns a 4xx/5xx (not 200 with an empty list), and the route table already in memory is left untouched

Verification

pytest practice_tickets/tests/test_ticket_07_loader_swallows_validation_errors.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/loader-swallows-validation-errors

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/loader-swallows-validation-errors

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Dynamic API Gateway & Reverse Proxy

A FastAPI reverse proxy that streams every request and response without ever buffering a body in full, with hot-reloadable routing, per-route auth, Redis token-bucket rate limiting, and a per-upstream circuit breaker.

Fork on GitHub

Download

Setup

Dynamic API Gateway & Reverse Proxy

git clone <your-fork>
cd FastAPIDevTraining/gateway_proxy
cp .env.example .env   # adjust GATEWAY_ADMIN_TOKEN etc. if you like
docker compose up --build   # Redis + the gateway (uvicorn --reload) + 2 demo upstreams

The gateway is reachable at . Two demo upstreams come up alongside it — (low-latency JSON echo at , plus for the streaming-passthrough demo) and (, , for timeout and circuit-breaker demos) — and wires five example routes against them, one per feature. Verify the stack with (liveness only) and (pings Redis, which every rate-limited route depends on). Every endpoint (route CRUD, reload, persist, breaker snapshot) requires .