tests/test_generate_images.py::test_generate_og_images collides with itself under concurrent pytest runs (fixed-name temp dir under the real repo root, not inside pytest's tmp_path)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
Research direction
The issue is in tests/test_generate_images.py in the test_generate_og_images function. Look at how test_root is constructed using script.ROOT and tmp_path.name. The fix is to use the unique tmp_path provided by pytest instead. Read the test to understand the monkeypatching of output directories. Run the test locally and reproduce the concurrency issue to verify the fix. Ensure the test passes and no stray directories are left after cleanup.
Written by the indexing model from the issue text.
Description
Where: tests/test_generate_images.py, test_generate_og_images - specifically test_root = script.ROOT / f".tmp-test-{tmp_path.name}" followed by test_root.mkdir().
The gap: The test builds its scratch directory as script.ROOT / f".tmp-test-{tmp_path.name}" - i.e. under the real repository root (script.ROOT, a fixed path shared by every process), using only tmp_path.name (e.g. "test_generate_og_images0", which is deterministic per pytest session/worker, not globally unique) rather than the full, process-unique tmp_path. Two concurrent pytest invocations therefore compute the identical test_root path and race on mkdir().
Repro (single run passes cleanly):
$ python3 -m pytest tests/test_generate_images.py::test_generate_og_images -q
1 passed in 5.92s
Repro (two concurrent runs collide):
$ (python3 -m pytest tests/test_generate_images.py::test_generate_og_images -q > /tmp/run1.log 2>&1 &)
$ (python3 -m pytest tests/test_generate_images.py::test_generate_og_images -q > /tmp/run2.log 2>&1 &)
$ sleep 8; cat /tmp/run2.log
FAILED tests/test_generate_images.py::test_generate_og_images - FileExistsError: [Errno 17] File exists: '/Users/.../Fair-Code/.tmp-test-test_generate_og_images0'
The failing process hits FileExistsError on the mkdir() call itself, which sits before the try/finally cleanup block, so its own shutil.rmtree cleanup never even applies to it - the surviving directory is only ever cleaned up by whichever process created it, making the outcome timing-dependent. Confirmed no stray directory or git changes were left behind after a normal run (git status --short clean), but a differently-timed collision could leave one.
Fix direction: Use tmp_path itself (already unique per test invocation) or tmp_path_factory's base temp dir instead of constructing a new path under script.ROOT; if the script under test requires monkeypatching absolute output directories anyway (which this test already does), there's no need for test_root to live under the repo root at all.
- Dominant language
- HTML
- Stars
- 47
- Forks
- 45
- Avg merge
- 1h 55m
- Merged PRs (30d)
- 99
Getting set up
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 yakew7/Fair-Code
-
bug documentation
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
Maintainers usually reply within 1 day
-
bug documentation
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
enhancement help wanted
Difficulty 4/5 3-5 days Newbie friendliness 58/100
Maintainers usually reply within 1 day
All issues in yakew7/Fair-Code
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
melgarafael/DeskcommCRM#1811 ·
Maintainers usually reply within 1 day
-
agent-reported area/browser bug good first issue hacktoberfest help wanted P2
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
Maintainers usually reply within 2 days
-
area: tests perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Nitjsefnie-Harness-Commons/daedalus#1255 ·
Maintainers usually reply within 1 day
-
area:casework bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
registrystack/registry-stack#1623 ·
Maintainers usually reply within 1 day