fix: catch aiohttp.ClientError in all API call functions (#29) #57
No reviewers
Labels
No Label
ai-changes-requested
ai-failed
ai-pr-opened
ai-reviewed
ai-reviewing
ai-working
ai-working
bug
enhancement
feature
in-queue
performance
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-discord#57
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "ai/paper-dynasty-discord-29"
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?
Summary
api_calls.pywas catchingasyncio.TimeoutErrorbut notaiohttp.ClientError, so DNS failures and refused connections raised raw, unformatted exceptions visible to Discord users.Added
except aiohttp.ClientError as ehandlers to all five API functions:db_get— logs error, raisesDatabaseError(no retry, since connection errors differ from transient timeouts)db_patch— logs error, raisesDatabaseErrordb_post— logs error, raisesDatabaseErrordb_put— logs error, raisesDatabaseErrordb_delete— logs error, raisesDatabaseErrorFiles Changed
api_calls.py— 15 lines added (3 per function × 5 functions)Test Results
No test suite. Changes verified by reading back the modified file and reviewing
git diff.AI Code Review
Files Reviewed
api_calls.py(modified)Findings
Correctness
except aiohttp.ClientError as eadded to all five functions (db_get,db_patch,db_post,db_put,db_delete).except asyncio.TimeoutErrorappears beforeexcept aiohttp.ClientErrorin all handlers. These two hierarchies don't overlap (asyncio.TimeoutErroris not a subclass ofaiohttp.ClientError), so ordering is safe.db_get, the new handler is correctly placed inside the retry loop, causing an immediateDatabaseErrorraise without retry — consistent with the PR's stated rationale that connection errors (DNS, refused connections) won't resolve within a retry window.DatabaseErroris the right exception type here — it's already raised for non-200 HTTP responses and is presumably caught/formatted by the cog layer before reaching Discord users.Security
{e}in the error message is from an aiohttp internal exception, logged server-side only and wrapped inDatabaseError— not directly exposed to Discord output.Style & Conventions
asyncio.TimeoutErrorhandlers).Suggestions
db_getdocstring'sRaisessection currently only documentsAPITimeoutErrorandDatabaseError(for non-200). The newDatabaseErrorfor connection errors is a third raise path not documented. Minor gap, no blocker.Verdict: APPROVED
Minimal, correct fix for a real bug. The implementation is consistent, the exception hierarchy is handled in the right order, and the no-retry decision for connection errors is sound. No blocking issues.
Automated review by Claude PR Reviewer
85b7980d6etod150e66bc7