[Fix] AttributeError crash in abort-testing on request timeout - #128
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe abort-testing command now checks Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The timeout handler now checks the exception field that holds the wrapped error. No actionable merge-blocking risk remains in the supplied review context. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Queued — the merge queue status continues in this comment ↓. |
oxesoft
left a comment
There was a problem hiding this comment.
Verified: ResponseHandlingException stores the wrapped exception as .error (no .source), and send_inner wraps httpx timeouts in it. Fix is correct.
Merge Queue Status
This pull request spent 14 seconds in the queue, including 2 seconds running CI. Required conditions to merge |
Fix: project-chip/certification-tool#1152
Fixes crash reported when running th-cli abort-testing — request would time out and instead of printing "Abort request sent (backend may still be processing)", it crashed with AttributeError: 'ResponseHandlingException' object has no attribute 'source'.
ResponseHandlingException stores the wrapped exception as .error, not .source. The timeout-handling branch in
abort_testing.pychecked the wrong attribute, so it never worked — any real timeout hit the AttributeError instead of the intended graceful message.Change:
cli/th_cli/commands/abort_testing.py— e.source → e.error.Testing: Reproduced by temporarily lowering the client timeout to force a ReadTimeout; confirmed it now prints "Abort request sent (backend may still be processing)" instead of crashing.