Nobody has started this yet — be first.
Business impact
The rating scale is documented and enforced everywhere else in this app as 1-10 (see MovieEntryUpdateSchema, the model column, and every existing test that mentions "rating"). But creating a new entry with the single most meaningful value on that scale -- a perfect 10 -- fails validation. A user rating their favorite movie ever gets a 422 on the one input the UI told them was valid. This is exactly the kind of "the app is broken" bug that generates confused support messages and bad reviews, because it happens on the happy path, not an edge case anyone would think to avoid.
Problem
POST /api/movies with "rating": 10 returns 422 validation_error. "rating": 9 and below are accepted; "rating": 11 and above are (correctly) rejected.
Current behavior
Creating a movie entry with the single most meaningful rating on the documented 1-10 scale -- a perfect 10 -- fails validation, and the error message gives away the bug: it claims the valid range tops out at 9.
Expected behavior
POST /api/movies with "rating": 10 must succeed (201) and return the entry with "rating": 10, exactly like any other value from 1-10.
Steps to reproduce
curl -s -X POST localhost:5000/api/movies -H "Authorization: Bearer $TOKEN"
-H "Content-Type: application/json"
-d '{"title": "A Perfect Ten", "rating": 10}'
Why this matters
MovieEntrySchema.rating validates with validate.Range(min=1, max=9). This is a classic off-by-one: the intended, documented, and elsewhere-enforced scale is 1-10 inclusive, but the upper bound here is one short of it.
Suggested approach
Compare MovieEntrySchema.rating's validate.Range(...) call in app/blueprints/movies/schemas.py against the identical field on MovieEntryUpdateSchema a few lines below it, and against the MovieEntry.rating column comment/usage in app/models.py. One of these disagrees with the other two.
Acceptance criteria
Verification
cd flask/movie_watchlist && .venv/bin/python -m pytest practicetickets/test_ticket02_rating_upper_bound.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/rating-upper-boundFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/rating-upper-boundSubmit 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 inRun the existing test suite (uses an in-memory SQLite DB, no setup needed):
.venv/bin/python -m pytest -v # 33 passed, 0 failed on a clean checkout
cp .env.example .env
# edit .env: set SECRET_KEY, JWT_SECRET_KEY, POSTGRES_PASSWORD to real values
docker compose up --build
This builds the web image, starts Postgres (db), waits for its healthcheck, then runs flask db upgrade and starts gunicorn -- all with one command, no manual migration step. The API is then available at http://localhost:5000.
Work the tickets in practicetickets/ (TICKET_01 through TICKET_07); each names one pytest test file in the same directory. This directory is outside pytest.ini's testpaths = tests, so a bare pytest run from the project root never picks these up -- they only run when pointed at directly:
cd flask/movie_watchlist
.venv/bin/python -m pytest practicetickets/test_ticket01_movie_list_ordering.py -v # a single ticket
./practicetickets/run_tickets.sh # all 7, clean pass/fail summary
run_tickets.sh also unsets TEST_DATABASE_URL/DATABASE_URL for its own run, so a leftover Postgres URL from a different project in your shell doesn't get picked up instead of the in-memory SQLite DB these tests are written against.
Level 1
Fix a bug
Read existing behaviour, correct it.