feat: add limit/pagination to scout_claims endpoint (#149) #151
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#151
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "issue/149-feat-add-limit-pagination-to-scout-claims-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 #149
Adds an optional
limitquery parameter toGET /api/v2/scout_claims:100500(clamped viamax(0, min(limit, 500)))limit=Noneis handled — no.limit()call appliedThe clamp uses
max(0, ...)to guard against negative values (PostgreSQLLIMIT -1would return all rows).Files changed:
app/routers_v2/scout_claims.pyOther observations:
ScoutOpportunitywas imported but unused (pre-existing) — removed by the ruff pre-commit hook enforcement to allow the commit to proceed.AI Code Review
Files Reviewed
app/routers_v2/scout_claims.py(modified).gitea/workflows/build.yml(in diff — pre-existing changes already inmain, no-op on merge)Findings
Correctness
limitdefaults to100, is clamped viamax(0, min(limit, 500)), and is applied only when notNone. Logic is correct.countfield in the response reflects the number of rows returned (after limiting), not the total number of matching rows. For example, if 300 claims match the filters butlimit=100,countreturns100. A caller implementing pagination cannot determine if there are more pages without an additional request. This is the same pattern as the notifications endpoint (PR #150) — consistent with the existing codebase, but worth noting if this endpoint ever needs to support cursor/offset pagination.Security
GETendpoint is unauthenticated (consistent with the existing endpoint).limitis typedOptional[int]so FastAPI rejects non-integer inputs automatically.Style & Conventions
ScoutOpportunityunused import correctly removed. Matches ruff enforcement in the project.Suggestions
countsemantics are important to callers, consider renaming itreturned_countor adding a separatetotal_countfield (requires an additionalSELECT COUNT(*)before applying.limit()). Non-blocking — pre-existing pattern.Note on
build.ymlThe
build.ymlchanges appear in the diff because this branch was cut before commitse12dac3andd4d93cdlanded onmain. The diff is already present inmain— the merge will be a no-op for that file.Verdict: COMMENT
Implementation is correct and the negative-value guard (
max(0, ...)) is properly applied — this is an improvement over the parallel notifications PR (#150). The one observation aboutcountsemantics is pre-existing and non-blocking.Automated review by Claude PR Reviewer
Approving after positive reviewer verdict. Implementation is correct, style matches conventions, no blocking issues.