feat: add limit/pagination to gauntletrewards endpoint (#145) #165

Claude · 2026-03-24T11:02:13Z

Claude commented

2026-03-24 11:02:13 +00:00

Closes #145

Adds limit query parameter to GET /api/v2/gauntletrewards.

Changes

limit: int = 100 added to v1_gauntletreward_get
Capped via max(0, min(limit, 500)) — guards negative values and upper bound
.limit() applied after all filters and ordering, before count and iteration
count reflects limited count (consistent with pre-existing pattern across paginated endpoints)

Files Changed

app/routers_v2/gauntletrewards.py

Closes #145 Adds `limit` query parameter to `GET /api/v2/gauntletrewards`. ## Changes - `limit: int = 100` added to `v1_gauntletreward_get` - Capped via `max(0, min(limit, 500))` — guards negative values and upper bound - `.limit()` applied after all filters and ordering, before count and iteration - `count` reflects limited count (consistent with pre-existing pattern across paginated endpoints) ## Files Changed - `app/routers_v2/gauntletrewards.py`

Claude added 1 commit 2026-03-24 11:02:14 +00:00

feat: add limit/pagination to gauntletrewards endpoint (#145 ) 2da984f1eb

Closes #145

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Claude referenced this pull request

2026-03-24 11:02:20 +00:00

feat: add limit/pagination to gauntletrewards endpoint #145

Claude added the

ai-reviewing

label 2026-03-24 11:15:47 +00:00

Claude reviewed 2026-03-24 11:16:26 +00:00

Claude left a comment

AI Code Review

Files Reviewed

app/routers_v2/gauntletrewards.py (modified)

Findings

Correctness

limit: int = 100 added correctly as a query parameter.
Clamping max(0, min(limit, 500)) is correct — guards both negative values and the upper bound. Consistent with all prior pagination PRs (#155–#162).
.limit() applied after all five filter branches (name, gauntlet_id, reward_id, win_num, loss_max) and both order_by calls, before count and iteration — placement is correct.
No CSV path in this endpoint, so no split-path concern.
count reflects the limited count (not total matching rows) — consistent with the pre-existing pattern across 12 of 13 paginated endpoints (exception: gauntletruns PR #160 which computes total count). Callers fetching paginated data won't know the true total, but this is a pre-existing design choice, not introduced here.

Security

No issues. limit is a plain integer, clamped before use in the ORM query.

Style & Conventions

limit: int (not Optional[int]) — same cosmetic inconsistency as PRs #157, #159, #162; both type annotations behave identically in FastAPI. Non-blocking.
No unnecessary ruff fixes or reformatting in this diff — clean, focused change.

Suggestions

MINOR: limit=0 returns an empty response even when rewards exist. A lower bound of 1 would prevent this confusing edge case, but this is consistent with all prior pagination PRs and not worth blocking here.
MINOR: count reflects limited count rather than total matching rows — a project-wide follow-up issue to add a total field (or rename count to limited_count) would benefit all 13 paginated endpoints at once.

Verdict: COMMENT

Implementation is correct and follows the established pagination pattern precisely. Posting as COMMENT rather than APPROVED due to Gitea self-review restriction. Ready to merge.

Automated review by Claude PR Reviewer

## AI Code Review ### Files Reviewed - `app/routers_v2/gauntletrewards.py` (modified) ### Findings #### Correctness - `limit: int = 100` added correctly as a query parameter. - Clamping `max(0, min(limit, 500))` is correct — guards both negative values and the upper bound. Consistent with all prior pagination PRs (#155–#162). - `.limit()` applied after all five filter branches (`name`, `gauntlet_id`, `reward_id`, `win_num`, `loss_max`) and both `order_by` calls, before `count` and iteration — placement is correct. - No CSV path in this endpoint, so no split-path concern. - `count` reflects the limited count (not total matching rows) — consistent with the pre-existing pattern across 12 of 13 paginated endpoints (exception: gauntletruns PR #160 which computes total count). Callers fetching paginated data won't know the true total, but this is a pre-existing design choice, not introduced here. #### Security - No issues. `limit` is a plain integer, clamped before use in the ORM query. #### Style & Conventions - `limit: int` (not `Optional[int]`) — same cosmetic inconsistency as PRs #157, #159, #162; both type annotations behave identically in FastAPI. Non-blocking. - No unnecessary ruff fixes or reformatting in this diff — clean, focused change. #### Suggestions - **MINOR**: `limit=0` returns an empty response even when rewards exist. A lower bound of 1 would prevent this confusing edge case, but this is consistent with all prior pagination PRs and not worth blocking here. - **MINOR**: `count` reflects limited count rather than total matching rows — a project-wide follow-up issue to add a `total` field (or rename `count` to `limited_count`) would benefit all 13 paginated endpoints at once. ### Verdict: COMMENT Implementation is correct and follows the established pagination pattern precisely. Posting as COMMENT rather than APPROVED due to Gitea self-review restriction. Ready to merge. --- *Automated review by Claude PR Reviewer*

Claude added

ai-reviewed

and removed

ai-reviewing

labels 2026-03-24 11:16:45 +00:00

cal approved these changes 2026-03-24 12:04:51 +00:00

cal left a comment

Approved. Reviewer found no blocking issues — implementation is correct and consistent with the established pagination pattern.

cal added 1 commit 2026-03-24 12:05:13 +00:00

Merge branch 'main' into issue/145-feat-add-limit-pagination-to-gauntletrewards-endpo a5857ff353

cal added 1 commit 2026-03-24 12:05:59 +00:00

Merge branch 'main' into issue/145-feat-add-limit-pagination-to-gauntletrewards-endpo e79fe8384f