feat: add limit/pagination to paperdex endpoint (#143) #167
No reviewers
Labels
No Label
ai-changes-requested
ai-failed
ai-merged
ai-pr-opened
ai-reviewed
ai-reviewing
ai-reviewing
ai-working
bug
enhancement
evolution
performance
phase-0
phase-1a
phase-1b
phase-1c
phase-1d
security
tech-debt
todo
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cal/paper-dynasty-database#167
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "issue/143-feat-add-limit-pagination-to-paperdex-endpoint"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #143
Adds
limit: int = 100query parameter toGET /api/v2/paperdex, capped at 500 viamax(0, min(limit, 500)). Applied after all filter branches so both CSV and JSON response paths honour the limit.Changes
app/routers_v2/paperdex.py: Addedlimitparam and cap logicOther observations
f"There are no paperdex to filter") — fixed to unblock pre-commit hookall_setsvariable incardset_idfilter branch — removed to unblock pre-commit hookAI Code Review
Files Reviewed
app/routers_v2/paperdex.py(modified)Findings
Correctness
limit: int = 100added toGET /api/v2/paperdex; capped viamax(0, min(limit, 500))— correct, guards both negative values and upper bound ✅.limit()applied after all 5 filter branches (team_id,player_id,cardset_id,created_after,created_before), before theif csv:branch — both CSV and JSON response paths honour the limit ✅all_setsunused variable in thecardset_idbranch correctly removed (ruff F841) — theall_dex.where(Paperdex.player.cardset.id == cardset_id)line that followed it was always the operative line ✅f"There are no paperdex to filter"→ plain string (ruff F541) — correct side-effect fix ✅Security
Style & Conventions
limit: int(notOptional[int]) — same cosmetic inconsistency as PRs #157, #159, #162, #165, #166; FastAPI handles both identically; non-blockingcountin JSON response reflects the limited count, not total matching records — consistent with 13 of the other 14 paginated endpoints (onlygauntletrunsfrom PR #160 uses total count); non-blockingSuggestions
Verdict: COMMENT
✅ Correct implementation.
limitparam added with proper cap, applied after all filters so both response paths (CSV and JSON) are bounded. Ruff cleanups (all_setsremoval, f-string fix) are appropriate. Posted as COMMENT due to Gitea self-review restriction; would otherwise be APPROVED.Automated review by Claude PR Reviewer
Approved as cal — reviewer verdict is effectively APPROVED (COMMENT state only due to Gitea self-review restriction). Implementation is correct and follows established patterns.