fix: raise HTTP errors from ApiClient instead of returning None - #1277
fix: raise HTTP errors from ApiClient instead of returning None#1277sankalpsthakur wants to merge 2 commits into
Conversation
|
Cross-linked on #1089. Prefer maintainers pick one of the two rather than both landing. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1277 +/- ##
==========================================
+ Coverage 89.70% 90.01% +0.31%
==========================================
Files 48 48
Lines 4778 4767 -11
==========================================
+ Hits 4286 4291 +5
+ Misses 492 476 -16 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Call raise_for_status after logging API failures so callers get meaningful errors, catch failures in EmissionsTracker so tracking continues offline, and update tests that assumed silent None returns. Fixes mlco2#820 Co-authored-by: Cursor <cursoragent@cursor.com>
594bb34 to
2b43f3a
Compare
|
Thanks for you contribution. It seems it need some improvements. Here is the review of Opus 5: OverviewTurns I verified the propagation paths: Issues1.
|
|
Rebased onto master. The 2 codecov/patch misses are the defensive |
_raise_api_error now raises for any unexpected status (including 2xx/3xx), CLI commands print friendly errors, and tests cover the unexpected-2xx path.
|
Thanks @benoit-cty — addressed the Opus review:
Skipped the tracker |
Description
ApiClientnow callsresponse.raise_for_status()after logging HTTP failures instead of returningNone/False/[]. Callers get realrequests.exceptions.HTTPErrors (and connection errors are re-raised from_create_run/add_emission).EmissionsTrackerwraps Code Carbon API output initialization in try/except so tracking continues without API reporting if setup fails. Removed the CLIorganization is Noneguard that assumed silent failure, and dropped theorganizations is Nonecheck incheck_organization_exists.Related Issue
Fixes #820
Motivation and Context
Silent
Nonereturns made API failures hard to debug and could confuse callers (e.g. iterating overNone). The issue asks forraise_for_statusin the client while keeping the tracker resilient.Note: #1089 is an earlier approved attempt that is stale with failing CI and does not wrap tracker API init. Happy to close this in favor of a refreshed #1089 if maintainers prefer.
How Has This Been Tested?
Results: all targeted tests passed (26 for api/http/tracker slice; 24 CLI).
Types of changes
Direct
ApiClientcallers that previously checked forNoneon HTTP errors will now see raised exceptions (intended). Tracker/live emission paths catch and log.AI Usage Disclosure
Please refer to docs/how-to/ai-policy.md for detailed guidelines on how to disclose AI usage in your PR. Accurately completing this section is mandatory.
AI coding tools were used to help draft the change and this PR description. I reviewed the complete change, understand the reasoning, and ran the reported local tests before submitting.
Checklist:
Made with Cursor