Nobody has started this yet — be first.
Business impact
Operators use DELETE /admin/routes/{id} to pull a route out of service -- decommissioning an old upstream, cutting off a route someone misconfigured, removing access during an incident. Right now that does not work: deleting a route that is actually in the table always 404s, so the only way to remove a route is a full POST /admin/routes/reload from a hand-edited routes.yaml (a much riskier, all-or-nothing operation) or restarting the process. During an incident where the fastest fix is "just take this one route out," that extra friction costs real time.
Problem
RouteTable.delete() raises RouteNotFoundError -- which the admin API turns into a 404 -- for exactly the routes that DO exist, and silently "succeeds" (204, no-op) for route IDs that do not exist.
Current behavior
delete()'s existence check is inverted: the condition guarding the "raise RouteNotFoundError" branch is testing membership in self._by_id the wrong way around, so the raise and no-op branches fire for the opposite cases from what "not found" should mean.
Expected behavior
Deleting a route ID that exists in the table removes it and returns 204. Deleting a route ID that does not exist returns 404.
Steps to reproduce
Why this matters
This is an inverted boolean condition -- the kind of one-character mistake that a quick manual test with a route ID that does not exist yet ("does deleting a nonexistent route correctly 404?" -- yes! by accident) would never catch, because the bug only shows up on the path most people do not think to double-check: deleting something that is actually there.
Suggested approach
Read the two lines of delete() closely: one condition decides whether to raise RouteNotFoundError, and it is testing for the wrong thing relative to what "not found" should mean.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_04_delete_route_inverted_check.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
Sign in to create it automatically, or do it yourself:
$git checkout -b fix/delete-route-inverted-checkFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/delete-route-inverted-checkSubmit it below
Paste your fork URL and the branch name, with a short write-up of the root cause.
Questions
Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.
Sign in to ask a question or reply.
Sign inhttp://localhost:8080fast_echo/echo/.../large/{size_mb}slow_upstream/delay/{s}/flaky/always-downroutes.yamlcurl localhost:8080/healthzcurl localhost:8080/readyz/admin/*Authorization: Bearer <GATEWAY_ADMIN_TOKEN>You do not need Docker running at all to work the tickets — the test suite fakes Redis with fakeredis (plus lupa for real Lua-script support), so everything runs against a plain virtualenv:
python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt
.venv/bin/pytest practice_tickets/tests/test_ticket_09_breaker_threshold_off_by_one.py -v # a single ticket
./practice_tickets/run_tickets.sh # all 15, clean pass/fail summary
./practice_tickets/run_tickets.sh 06 09 15 # just a few, by number
All 15 tests fail at the start; as you fix each ticket in app/, its test (and only its test) should flip to passing. .venv/bin/pytest tests/ runs the project's own main suite — as of writing it shows 8 pre-existing failures caused by ticket bugs 02, 04, 06, and 09; fixing those tickets fixes those failures too, not a separate task.
Level 1
Fix a bug
Read existing behaviour, correct it.