Repository navigation
fix: propagate the API run id to the tracker - #1327
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1327 +/- ##
==========================================
+ Coverage 93.86% 93.95% +0.09%
==========================================
Files 51 51
Lines 5734 5757 +23
==========================================
+ Hits 5382 5409 +27
+ Misses 352 348 -4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
08cdabf to
0221c73
Compare
Verdict: ✅ Approve with one fix suggestedThe bug is real. With API output, Issue to fix: CSV and API ids can still differ (medium)
Nits:
|
|
Made the changes in d53e2de: run_id now syncs to the API run once it's created late (with a test for API down at start then recovering), the start() fallback logs once as a warning, docs mention the blocking call and the run_id switch, PR description fixed, and master merged in. |
d53e2de to
f75bb46
Compare
|
Rebased onto
Open items:
Generated by Claude Code |
|
@benoit-cty @inimaz #1327, #1340 and #1334 are rebased on current master, mergeable, and CI is green. Could you review them? Suggested merge order:
|
The tracker generated its own run_id and never picked up the one the API created, so API-backed runs persisted a local uuid (or the string "None") instead of the run id the server knows about. Create the API run in start(), where the output handler is already wired, and adopt its run id when there is one. run_id stays a plain writable attribute. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Log the start() fallback once as a warning, and document the blocking run creation and the run_id switch. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ning The API client already logs why run creation failed, so the start() warning only states the consequence (local run_id is used). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JfRKgUd281URY6fMyNAQmh
start_task()/stop_task() never call start(), so with the API output the run was only created by the API handler in stop(), after the CSV rows and task files were written. Task records and emissions_base_<run_id>.csv carried a local uuid that never matched the API run id. start() and start_task() now share _adopt_api_run(). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ates it _prepare_emissions_data() only synced run_id with a run created earlier: the run itself was created afterwards, inside the API handler. When the API was down at start() and came back at stop(), every CSV row and tracker.run_id kept the local id while the API stored the data under a new run, and nothing was logged. The record written at recovery also got the local id. The tracker now tries to create the run before building each record. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
f75bb46 to
1da1650
Compare
…sk() With the API unreachable, start_task() tried to create the run twice (explicitly, then in _prepare_emissions_data), even when refused because a task was already active, and stop_task() tried again before computing the task duration, so a blocking request of up to the 2 s timeout was counted in the task duration. start_task() now tries once, after the active-task check, and stop_task() does not try: its record is not sent anywhere. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
_prepare_emissions_data() tries to create the missing API run, then CodeCarbonAPIOutput._emit() tried again for the same record. With the API unreachable, every flush(), stop() and live update waited twice for the timeout (the live update while holding the measurement lock) and logged the error twice. The tracker now builds its API output with create_run_on_emit=False: the output skips the emission when the run is still missing, as master did after a failed creation. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Behaviour changes
Overlap with #1340: it adds a cooldown to |
Without a codecov.yml, Codecov computed codecov/project from the first uploads. While the Windows job was still running, Windows-only code (windows_emi.py, hardware.py) looked uncovered and codecov/project failed at -0.31% on a PR that does not touch it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Description
EmissionsTracker.run_idused to start as a locally generated uuid and never got updated once the API created its own run id, becauseCodeCarbonAPIOutputcreates the API run lazily and nothing wrote the resulting id back onto the tracker. This PR moves the API run creation intostart()and makesrun_idswitch to the API run id as soon as it exists. If the API is down atstart(),run_idswitches as soon as a later emission creates the run, with a warning that earlier records used the local id.Related Issue
Fixes #1303
Motivation and Context
With
OutputMethod.APIenabled,tracker.run_idstayedNoneand_prepare_emissions_datarecorded the literal string"None"in every row. This broke joining CSV data with API data, brokeon_csv_write="update"(it matched on"None"and overwrote the previous run's row), and caused per-task / BOAMPS filenames to collide on..._None.csv.How Has This Been Tested?
tests/test_emissions_tracker.py::TestCarbonTracker::test_run_id_with_api_output_is_never_noneassertstracker.run_idis notNoneand that the run id written toemissions.csvmatches the API run id. It fails onmasterand passes with this change.uv run pytest tests/test_emissions_tracker.py tests/output_methods tests/test_tracking_inference.py tests/test_api_call.py -qpasses locally.Screenshots (if appropriate):
N/A
Types of changes
AI Usage Disclosure
Checklist: