fix: ensure count is never null in GET /refractor/cards (#183) #185
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
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cal/paper-dynasty-database#185
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "issue/183-bug-get-refractor-cards-returns-count-null-with-ve"
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 #183
Summary
query.count()on a complex multi-join query (RefractorCardState → RefractorTrack → Player via LEFT JOIN) can returnNonein Peewee 3.17.9 when 0 rows match the filter set. This caused{"count": null, "items": []}responses instead of{"count": 0, "items": []}.Fix
Added
or 0guard tototal = query.count()→total = query.count() or 0inlist_card_states().The existing
limit: int = Query(default=10, ge=1, le=100)constraint already rejectslimit=99999with 422 — no change needed there.Files Changed
app/routers_v2/refractor.py— 1 lineOther observations
GET /{team_id}/refractorsinteams.py(line 1579) has the sametotal = query.count()pattern without theor 0guard. Same Peewee bug applies there — tracked separately.AI Code Review
Files Reviewed
app/routers_v2/refractor.py(modified — 1 line)CLAUDE.md(modified — doc fix, auto-resolves)Findings
Correctness
total = query.count() or 0— correct guard. Peewee 3.17.9 can returnNonefrom.count()on a multi-table LEFT JOIN query when 0 rows match. Theor 0idiom is the established pattern already applied elsewhere in this codebase (matching the fix in PR #184). Applied at the right place — after all filters, before pagination. ✅CLAUDE.mdhunk: updates dev PostgreSQL container/db/user info. This duplicates commitcc65dc5already onmain— a stale hunk from the branch cut. Gitea reportsmergeable: true, so it auto-resolves cleanly on merge. ✅Security
Style & Conventions
Suggestions
issue/182-...) fixes the identical line and was created ~27 minutes earlier, but is currentlymergeable: false(merge conflict). This PR (#185) ismergeable: trueand is effectively the better candidate. Recommend closing #184 in favor of this PR to avoid confusion.teams.py:1579follow-up (samequery.count()pattern without guard, also without thege=0,le=4tier constraint) is already noted in the PR body — tracked separately. ✅Verdict: COMMENT
Fix is correct and the PR is mergeable. Posting as COMMENT due to self-review restriction (author and reviewer are both Claude). Recommend closing PR #184 (not mergeable, duplicate) and merging this one.
Automated review by Claude PR Reviewer
Checkout
From your project repository, check out a new branch and test the changes.