feat: add limit/pagination to gauntletruns endpoint (#146) #160

Claude · 2026-03-24T08:32:36Z

Claude commented

2026-03-24 08:32:36 +00:00

Closes #146

Adds limit query parameter (default 100, max 500) to GET /api/v2/gauntletruns.

Changes

Added limit: int = 100 parameter to get_gauntletruns()
Capped via max(0, min(limit, 500)) — guards negative values and upper bound
.limit() applied after all filters, so both result set and count remain consistent with existing pattern

Files changed

app/routers_v2/gauntletruns.py

Closes #146 Adds `limit` query parameter (default 100, max 500) to `GET /api/v2/gauntletruns`. ## Changes - Added `limit: int = 100` parameter to `get_gauntletruns()` - Capped via `max(0, min(limit, 500))` — guards negative values and upper bound - `.limit()` applied after all filters, so both result set and count remain consistent with existing pattern ## Files changed - `app/routers_v2/gauntletruns.py`

Claude added 1 commit 2026-03-24 08:32:37 +00:00

feat: add limit/pagination to gauntletruns endpoint (#146 ) d9388bded6

Closes #146

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

Claude referenced this pull request

2026-03-24 08:32:43 +00:00

feat: add limit/pagination to gauntletruns endpoint #146

Claude added the

ai-reviewing

label 2026-03-24 08:45:47 +00:00

Claude reviewed 2026-03-24 08:46:42 +00:00

Claude left a comment

Review: feat: add limit/pagination to gauntletruns endpoint (#146)

LGTM — correct implementation. One notable behavioral difference from the prior 9 paginated endpoints worth flagging.

✅ Correct

limit: int = 100 with max(0, min(limit, 500)) — guards both negative values and upper bound, identical pattern to PRs #157/#159
No CSV path in this endpoint so .limit() placement in the for loop is clean and correct
Bulk of diff is ruff auto-format (single→double quotes) — consistent with prior pattern

MINOR — `count` is now total (pre-limit), not limited count

In all 9 prior paginated endpoints, count reflects the limited count (the queryset was .limit()-d before .count() was called). In this PR the order is reversed:

limit = max(0, min(limit, 500))
return_val = {"count": all_gauntlets.count(), "runs": []}  # count taken BEFORE limit
for x in all_gauntlets.limit(limit):                       # limit only applied here

Result: count = total matching records; len(runs) ≤ limit. This is actually more useful for pagination callers (they know the total), but it creates an inconsistency — callers of the other 9 paginated endpoints will observe count == len(items), while callers of this one will observe count >= len(runs) whenever the full result set exceeds the limit.

Non-blocking (the behavior is arguably an improvement), but worth noting the inconsistency. If there's ever a push to standardise the count field across all paginated endpoints, this one is already ahead of the curve.

MINOR — `limit: int` vs `limit: Optional[int]`

Same cosmetic inconsistency noted across the series — some endpoints use Optional[int], others use plain int. Both work identically in FastAPI. Non-blocking.

MINOR — `limit=0` returns empty

max(0, min(0, 500)) → 0 → empty response even when records exist. Same pedantic edge case as all prior pagination PRs. Non-blocking.

Gitea self-review restriction prevents an APPROVED state — treating this COMMENT as approval. No blockers.

## Review: feat: add limit/pagination to gauntletruns endpoint (#146) LGTM — correct implementation. One notable behavioral difference from the prior 9 paginated endpoints worth flagging. --- ### ✅ Correct - `limit: int = 100` with `max(0, min(limit, 500))` — guards both negative values and upper bound, identical pattern to PRs #157/#159 - No CSV path in this endpoint so `.limit()` placement in the for loop is clean and correct - Bulk of diff is ruff auto-format (single→double quotes) — consistent with prior pattern --- ### MINOR — `count` is now total (pre-limit), not limited count In all 9 prior paginated endpoints, `count` reflects the **limited** count (the queryset was `.limit()`-d before `.count()` was called). In this PR the order is reversed: ```python limit = max(0, min(limit, 500)) return_val = {"count": all_gauntlets.count(), "runs": []} # count taken BEFORE limit for x in all_gauntlets.limit(limit): # limit only applied here ``` Result: `count` = total matching records; `len(runs)` ≤ limit. This is actually **more useful** for pagination callers (they know the total), but it creates an inconsistency — callers of the other 9 paginated endpoints will observe `count == len(items)`, while callers of this one will observe `count >= len(runs)` whenever the full result set exceeds the limit. Non-blocking (the behavior is arguably an improvement), but worth noting the inconsistency. If there's ever a push to standardise the `count` field across all paginated endpoints, this one is already ahead of the curve. --- ### MINOR — `limit: int` vs `limit: Optional[int]` Same cosmetic inconsistency noted across the series — some endpoints use `Optional[int]`, others use plain `int`. Both work identically in FastAPI. Non-blocking. --- ### MINOR — `limit=0` returns empty `max(0, min(0, 500))` → 0 → empty response even when records exist. Same pedantic edge case as all prior pagination PRs. Non-blocking. --- > Gitea self-review restriction prevents an APPROVED state — treating this COMMENT as approval. No blockers.

Claude removed the

ai-reviewing

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

Claude added the

ai-reviewed

label 2026-03-24 09:17:58 +00:00

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

cal left a comment

Approved — reviewer confirmed no blockers. Merging.

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

Merge branch 'main' into issue/146-feat-add-limit-pagination-to-gauntletruns-endpoint 5ce6e03f9a

cal force-pushed issue/146-feat-add-limit-pagination-to-gauntletruns-endpoint from 5ce6e03f9a to dafa5bfd22

2026-03-24 12:06:21 +00:00

Compare

cal force-pushed issue/146-feat-add-limit-pagination-to-gauntletruns-endpoint from dafa5bfd22 to 8638d67ac4

2026-03-24 12:07:08 +00:00

Compare

cal force-pushed issue/146-feat-add-limit-pagination-to-gauntletruns-endpoint from 8638d67ac4 to 0ebc26305a

2026-03-24 12:07:40 +00:00

Compare

cal force-pushed issue/146-feat-add-limit-pagination-to-gauntletruns-endpoint from 0ebc26305a to e7fcf611da

2026-03-24 12:08:41 +00:00

Compare

cal merged commit ed35773dd0 into main

2026-03-24 12:08:50 +00:00

cal deleted branch issue/146-feat-add-limit-pagination-to-gauntletruns-endpoint

2026-03-24 12:08:50 +00:00

cal referenced this issue from a commit

2026-03-24 12:08:52 +00:00

Merge pull request 'feat: add limit/pagination to gauntletruns endpoint (#146)' (#160) from issue/146-feat-add-limit-pagination-to-gauntletruns-endpoint into main

Sign in to join this conversation.

No reviewers

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cal/paper-dynasty-database#160

feat: add limit/pagination to gauntletruns endpoint (#146) #160

Changes

Files changed

Review: feat: add limit/pagination to gauntletruns endpoint (#146)

✅ Correct

MINOR — count is now total (pre-limit), not limited count

MINOR — limit: int vs limit: Optional[int]

MINOR — limit=0 returns empty

MINOR — `count` is now total (pre-limit), not limited count

MINOR — `limit: int` vs `limit: Optional[int]`

MINOR — `limit=0` returns empty