Loading challenges
Nobody has started this yet — be first.
Business impact
Anyone reading the "last N days" click chart is looking at a chart for "the last N-1 days" without knowing it -- and for the common case of days=1 ("today"), the window shrinks to zero, so a link that was clicked moments ago can show up with zero clicks for "today." A marketing team deciding whether a campaign link is getting traction right now would see misleadingly low numbers on exactly the day they are most likely to be checking.
Problem
since = datetime.utcnow() - timedelta(days=days - 1). For days=7 (the default), this reaches back only 6 days. For days=1, timedelta(days=0) means since == now, which excludes essentially every click that already happened.
Current behavior
?days=1 returns clicks_per_day summing to 0 even immediately after a click, because ClickEvent.timestamp >= since requires the click to be at-or-after this same instant.
Expected behavior
since = datetime.utcnow() - timedelta(days=days) -- a window of days=N reaches back exactly N days, and always includes a click that just happened, regardless of what N is.
Steps to reproduce
Why this matters
"- 1" here reads like someone reasoning "day 1 through day N" as an inclusive range and subtracting one to convert to a timedelta, but that reasoning doesn't apply to a rolling time window measured in fractional days (not whole calendar days) -- datetime.utcnow() isn't midnight, so "the last N days" as a duration is exactly timedelta(days=N), full stop.
Suggested approach
Compare this line against the days parameter's own docstring/intent ("last 7-30 days") and against a simple sanity check: does a days=1 window include a click from one second ago? Walk through the arithmetic for days=1 by hand before deciding the fix.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_07_analytics_window.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/analytics-off-by-one-windowFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/analytics-off-by-one-windowSubmit 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 indocker-entrypoint.shcurl -X POST http://localhost:5000/api/urls \
-H "Content-Type: application/json" \
-d '{"target_url": "https://anthropic.com", "custom_slug": "claude"}'
# -> {"slug": "claude", "short_url": "http://localhost:5000/claude", "expires_at": null}
curl -i http://localhost:5000/claude # 302 redirect, records a click
make seed # or: docker compose exec web flask seed-db
If something is already listening on 5432/6379 locally, uncomment POSTGRES_HOST_PORT / REDIS_HOST_PORT in .env to remap the host side — the app always talks to db/redis over the compose network regardless. Run production-style (gunicorn, no dev server, no bind mount) with docker compose -f docker-compose.prod.yml up --build. GET /healthz checks both Postgres and Redis connectivity.
You do not need Docker running at all to work the tickets — the test suite uses TestingConfig (SQLite in-memory via StaticPool) and fakeredis instead of a real Postgres/Redis, 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_01_base62_roundtrip.py -v # a single ticket
./practice_tickets/run_tickets.sh # all 20, clean pass/fail summary
./practice_tickets/run_tickets.sh 05 13 16 # just a few, by number
All 20 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/ (via make test) runs the project's own main suite — some ticket bugs (TICKET-05, 07, 08, 09, 14 among others) also break assertions in that suite, since they are real bugs in shared code paths; fixing the ticket fixes those too, not a separate task.
Level 1
Fix a bug
Read existing behaviour, correct it.