Protect HIL report artifacts from interrupted writes
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
Research direction
Find the write_report function and the tests that cover report artifacts. Read how it currently writes REPORT_JSON and REPORT_MD, then check whether the tests can verify the temp-file-and-rename behavior. Done means both files are written to temporary files before os.replace is used for each, a test covers the behavior, and the docstring notes that the two renames are not transactional.
Written by the indexing model from the issue text.
Description
write_report commits the two artifacts non-atomically
Origin: split out of PR #3840, surfaced by its second review round. Close this issue
when its own PR lands.
md = render_report(doc) + '\n'
report_dir.mkdir(parents=True, exist_ok=True)
(report_dir / REPORT_JSON).write_text(json.dumps(doc, indent=2) + '\n')
(report_dir / REPORT_MD).write_text(md, encoding='utf-8')
Rendering before writing closed the render-failure case: a raise can no longer commit a
sidecar the markdown contradicts. It does not close the interrupted-between-writes case. A
kill between those two lines leaves the pair disagreeing — and this runs on the containment
path, on the way to os._exit, on a rig whose jobs get cancelled by the GitHub job ceiling.
What remains: write both to temp files, then os.replace both. The window shrinks from
two full writes to two renames, and neither file is ever observed half-written. os.replace
is atomic per file on POSIX; the pair is still not transactional, which is acceptable and
should be said in the docstring rather than implied away.
Worth pairing with a test that kills between the writes — or, more practically, one that
asserts no partial file is ever visible by checking the temp-then-rename shape directly.
Why it was split out
A durability edge, not a wrong verdict. PR #3840 closed the render-failure half of this
(nothing is written until the markdown renders); the interrupted-between-writes half needs
a temp-then-rename and is better reviewed on its own.
- Dominant language
- C
- Stars
- 7.2k
- Forks
- 1.6k
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 100
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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 hathach/tinyusb
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 1/5 Under an hour Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
followup Prio 📌
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
update-request
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
msys2/MINGW-packages#33004 ·
Maintainers usually reply within 1 day
-
area:buffer good first issue type:documentation
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sudo-project/sudo#586 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
OpenPrinting/cups#1795 ·
Maintainers usually reply within 1 day