Loading challenges
Nobody has started this yet — be first.
Business impact
event_stream() subscribes to pub/sub before reading the replay backlog specifically to close a race: a notification published in the gap between a client reconnecting with Last-Event-ID and the backlog read actually returning shows up on both paths -- once via replay, once via the live subscription that was already listening. The check that's supposed to drop that duplicate is wrong at exactly the boundary that matters: the case where the live copy's id equals the last id already delivered, which is precisely what happens during the race the whole mechanism exists to handle. A user reconnecting during exactly the wrong half-second sees one notification twice, undermining the exactly-once guarantee this feature is built around.
Problem
_is_newer's docstring promises it returns True only when a candidate id is strictly after a baseline id, but its comparison treats an equal id as newer too.
Current behavior
_is_newer('100-0', '100-0') (identical ids) returns True, when the function's own docstring says it should only be True for a candidate strictly after the baseline.
Expected behavior
_is_newer(candidate, baseline) must return False when candidate == baseline, matching its own docstring. A live message whose id was already delivered via backlog replay must never be re-delivered.
Steps to reproduce
python3 -c "from app.streaming import _is_newer; print(_is_newer('100-0', '100-0'))" -- prints True, though the docstring says an identical id is not "strictly after" and should return False.
Why this matters
vs >= on a single comparison is one of the easiest mistakes to make and one of the hardest to catch by reading code quickly -- both read as reasonable boundary checks, and the function behaves identically for every unequal pair of ids. Only the exact-equality case, which by construction only happens during the specific network-blip race this subsystem was designed around, exposes the difference. A bug that only manifests on the exact scenario a test suite is least likely to hit by accident is exactly the kind that ships.
Suggested approach
Compare the one-line body of _is_newer against what its own docstring says it should do. Think through what it means for candidate to count as "strictly after" baseline when the two are equal.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_07_duplicate_on_exact_id_match.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/duplicate-on-exact-id-matchFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/duplicate-on-exact-id-matchSubmit 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:8000http://localhost:8001Authorization: Bearer <user_id>X-User-Id: <user_id>curl localhost:8000/healthz
curl -N -H "Authorization: Bearer alice" localhost:8000/notifications/stream
# watch `: heartbeat` lines arrive roughly every 15s with no other traffic
Work the tickets in practice_tickets/tickets/ (ordered easy → hard); each names one dedicated pytest test in practice_tickets/tests/:
pytest practice_tickets/tests/test_ticket_01_heartbeat_default_margin.py -v # a single ticket
./practice_tickets/run_tickets.sh # all 15, clean pass/fail summary
Tickets 14 and 15 need genuinely concurrent, long-lived streams, which the ASGI test transport used everywhere else in this project can't represent -- their tests spin up a real (short-lived) uvicorn server on a loopback socket instead (LiveServer in practice_tickets/tests/conftest.py).
Level 1
Fix a bug
Read existing behaviour, correct it.