Builder: _ACTIVE_TELEMETRY is never cleared after a completed run, so an early exit in a later in-process main() call marks the PRIOR staging run failed
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 70/100
Research direction
Start in tools/build_us_fiscal_refresh_release.py, following main(), _staging_telemetry(), and the _ACTIVE_TELEMETRY global. Reproduce two in-process main() calls where the second exits early, then add the consecutive-invocation regression test described in the issue. Done means the second call does not mutate or re-upload the first run's telemetry.
Written by the indexing model from the issue text.
Description
Surfaced by the sol round-3 review of PR #674 (evidence tier) as PLAUSIBLE, pre-existing on main since #563's main()→_main() wrapper.
Mechanics (tools/build_us_fiscal_refresh_release.py): _ACTIVE_TELEMETRY is a module global set/reset only inside _staging_telemetry(); telemetry.complete() does not clear it. The main() wrapper calls _ACTIVE_TELEMETRY.fail(error) on any BaseException. So in one Python process, after a completed staging-enabled run, a second main() invocation that exits BEFORE _staging_telemetry() runs — argparse SystemExit, the dirty-worktree SystemExit, _refuse_certified_release_dir_reuse, or (#674) a malformed --evidence-failure-owners file — rewrites/re-uploads the PRIOR run as failed.
Reachability: nil for one-process-per-CLI-run usage (every launcher today); real for any driver or test harness that invokes main() repeatedly in-process.
Minimal fix: clear _ACTIVE_TELEMETRY = None at main() entry (and in a finally after the failure report), keeping the current run referenced long enough for exception reporting; plus a consecutive-invocation regression test asserting an early-exit second call never mutates the first run's telemetry. Left to the #563 lane rather than folded into #674, which only adds one more early-exit site to a pre-existing set.
🤖 Generated with Claude Code
- Dominant language
- Python
- Stars
- 0
- Forks
- 4
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 104
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PolicyEngine/microcosm
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
PolicyEngine/microcosm#475 ·
Maintainers usually reply within 1 day
-
UK: track the defects uk-data is fixing that microcosm still hasPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
PolicyEngine/microcosm#1095 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
PolicyEngine/microcosm#1094 ·
Maintainers usually reply within 1 day
-
ACS local release: real-data verification checklist for the first build of the #1019–#1023 stackOpen
Difficulty 5/5 Over a week Newbie friendliness 25/100
PolicyEngine/microcosm#1093 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
PolicyEngine/microcosm#1090 ·
Maintainers usually reply within 1 day
All issues in PolicyEngine/microcosm
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 91/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 92/100
-
enhancement P2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Toloka/tolokaforge#1776 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
TencentCloud/Octop#1622 ·
Maintainers usually reply within 1 day
-
arch area:fleet priority:p3 severity:low track:hosted-product
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day