The rankings endpoint validated year with le=2100, but the database stores academic-year codes like 201819, so any explicit year selection returned a 422 and the rankings page rendered its empty state (e.g. /rankings?local_authority=Wandsworth&year=201819).
Widen the bound to le=210100 so academic-year codes pass validation; out-of-range values are still rejected.
Extend the e2e rankings journey to pick a specific year from the dropdown and assert the table stays populated. This test fails against current production, reproducing the bug.
The rankings endpoint validated `year` with `le=2100`, but the database stores academic-year codes like `201819`, so any explicit year selection returned a 422 and the rankings page rendered its empty state (e.g. `/rankings?local_authority=Wandsworth&year=201819`).
- Widen the bound to `le=210100` so academic-year codes pass validation; out-of-range values are still rejected.
- Extend the e2e rankings journey to pick a specific year from the dropdown and assert the table stays populated. This test fails against current production, reproducing the bug.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The rankings endpoint validated year with le=2100, but the database
stores academic-year codes like 201819, so any explicit year selection
returned a 422 and the rankings page rendered its empty state. Widen
the bound to cover the codes and extend the e2e journey to pick a
specific year and assert the table stays populated.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fixes the /api/rankings endpoint's year query parameter validation, which previously rejected the 6-digit academic-year codes (e.g. 201819) actually stored in the year column, by widening the upper bound from 2100 to 210100. Adds a matching e2e test that selects a specific year on the rankings page and asserts the table stays populated. Verified against the dbt staging models (time_period cast to year) and the frontend's RankingsView (which already passes these codes as option values), and the fix is correctly scoped — no other endpoint uses this parameter.
✅ No issues found.
## 🤖 AI Code Review (Claude Code)
Fixes the `/api/rankings` endpoint's `year` query parameter validation, which previously rejected the 6-digit academic-year codes (e.g. `201819`) actually stored in the `year` column, by widening the upper bound from 2100 to 210100. Adds a matching e2e test that selects a specific year on the rankings page and asserts the table stays populated. Verified against the dbt staging models (`time_period` cast to `year`) and the frontend's `RankingsView` (which already passes these codes as option values), and the fix is correctly scoped — no other endpoint uses this parameter.
✅ No issues found.
tudor
merged commit 0a370e3b63 into main2026-07-05 10:46:04 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The rankings endpoint validated
yearwithle=2100, but the database stores academic-year codes like201819, so any explicit year selection returned a 422 and the rankings page rendered its empty state (e.g./rankings?local_authority=Wandsworth&year=201819).le=210100so academic-year codes pass validation; out-of-range values are still rejected.🤖 Generated with Claude Code
🤖 AI Code Review (Claude Code)
Fixes the
/api/rankingsendpoint'syearquery parameter validation, which previously rejected the 6-digit academic-year codes (e.g.201819) actually stored in theyearcolumn, by widening the upper bound from 2100 to 210100. Adds a matching e2e test that selects a specific year on the rankings page and asserts the table stays populated. Verified against the dbt staging models (time_periodcast toyear) and the frontend'sRankingsView(which already passes these codes as option values), and the fix is correctly scoped — no other endpoint uses this parameter.✅ No issues found.