Repository navigation
Test flake: isolate the lotor-mh- cleanup test from the shared temp dir - #96
Open
githubscum wants to merge 1 commit into
Open
githubscum wants to merge 1 commit into
githubscum wants to merge 1 commit into
Conversation
The count read the whole system temp dir, so parallel test files and other worktrees making lotor-mh- dirs failed it at random. Point TMPDIR/TEMP/TMP at a private dir for the test and restore in finally. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WO: WO-MH-TMPDIR-01. Source: lane run 77 / main-session note 2026-10-26 ("known flake", candidate limit). Test reliability, not a v3 rung: a suite that fails at random teaches the reviewer to rerun instead of read.
What changed: one test in
test/matcher-history.test.js("temp dirs prefixed lotor-mh- are cleaned up"). It counted everylotor-mh-*entry in the system temp dir, so any concurrent test file, worktree, or process makinglotor-mh-dirs moved the count (observed once: 39 vs 27). The test now points TMPDIR/TEMP/TMP at a privatemhiso-dir for its duration, asserts the override took effect, and restores the env (delete-or-assign) and removes the dir infinally. No source file touched; no pin re-stamp needed.Not a new limit: the defect was in the test, not in what Lotor witnesses, so nothing goes in KNOWN-LIMITS.
Tested:
npm test: 1379 tests, 1374 pass, 0 fail, 5 skipped (same as main).lotor-mh-noise-*dirs in the system temp dir every 15 ms, the test as on main fails (9/1); this version passes (10/0).Executor: glm-5.3-flash:cloud via dispatch-to-ollama. Lotor receipt session 33efeafa:
model: glm-5.3-flash, touched only this test file. It could not run node under acceptEdits and said so. Verification above is mine.Eval: none of E1-E6 (test hygiene).
Doubt:
os.tmpdir()at call time (src/views/matcher-history.js:117). If someone hoists that to module load, the leak check would look in the real temp dir again and go quiet in the private one. A short comment pins the dependency; a tripwire would be stronger.process.envinside a test is process-global. Tests in this file run in sequence, so nothing else sees it, but a future{ concurrency: true }on the describe would break that.