Loading challenges
Nobody has started this yet — be first.
Business impact
Any device/client that numbers its events starting at 0 (extremely common — it's the default for practically every counter, array index, and auto-increment convention in software) gets a 422 Unprocessable Entity on its very first event, before it has ever successfully sent anything. This isn't a degraded experience, it's a hard onboarding wall: support tickets show up as "the API rejects every single event we send," and a customer integrating for the first time has no way to know the fix is "start counting from 1" without reading this codebase's source.
Problem
EventIn.sequence is declared with a Pydantic Field constraint that rejects sequence=0 outright with a 422, before the request handler ever runs.
Current behavior
EventIn.sequence uses Field(default=None, gt=0) — gt ("greater than") excludes zero, so constructing or posting an event with sequence=0 raises a Pydantic ValidationError.
Expected behavior
sequence=0 must be accepted as a legitimate first value for a monotonic per-device counter; only negative values should be rejected.
Steps to reproduce
cd fastapi/ingest_service && .venv/bin/python -c "from app.schemas import EventIn; EventIn(device_id='d1', event_type='ping', sequence=0)"pydantic.ValidationError: Input should be greater than 0.Why this matters
gt=0 vs ge=0 is a one-character difference with a real semantic meaning: "greater than" excludes the boundary, "greater than or equal to" includes it. Zero-indexed sequences are the norm, not the exception, so the exclusive bound silently assumes 1-indexing where none was intended — a classic off-by-one at a validation boundary.
Suggested approach
Look at the Field(...) constraint on EventIn.sequence in app/schemas.py and decide which comparison actually matches "reject negative sequence numbers, accept zero and everything above."
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_02_sequence_zero.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/sequence-zero-rejectedFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/sequence-zero-rejectedSubmit 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:8000localhost:5432curl localhost:8000/healthzcurl localhost:8000/readyzWork the tickets in practice_tickets/tickets/ (ordered easy → hard); each names one dedicated test in practice_tickets/tests/:
pytest practice_tickets/tests/test_ticket_01_persisted_count.py -v # a single ticket
./practice_tickets/run_tickets.sh # all 20, clean pass/fail summary
TICKET-17 needs a real Postgres to run at all (it checks which column a value lands in, which no fake/in-memory DB backend can meaningfully verify) — set TEST_DATABASE_URL=postgresql://<you>@localhost/ingest_test before running it or the full suite; without it, that one test is skipped, not failed.
Level 1
Fix a bug
Read existing behaviour, correct it.