Repository navigation
plugin: keep a held session lock fresh, so the daily prune leaves it - #211
Merged
Saksham Uboweja (SakshamUboweja) merged 1 commit intoNov 11, 2026
Conversation
Taking a session's hook lock writes nothing to its file, so the file's mtime stayed at the session's first hook. Once the session was open for more than IDLE_S, `_prune` removed the lock file while a hook held it, and on POSIX the session's next hook locked a new file and ran beside the holder. The hook that takes the lock now touches its file first. Fixes microsoft#210 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Saksham Uboweja (SakshamUboweja)
merged commit Nov 11, 2026
26ff86b
into
microsoft:main
10 checks passed
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.
Fixes #210
A session's hook lock file (
locks/<host>/.<session>.lock) is created at the session's first hook. Taking the lock after that only opens and locks the file and writes nothing to it, so its mtime stays at that first hook._pruneremoves lock files older thanIDLE_S(2 days), and it runs while a hook holds its own lock. So once a session had been open for more than 2 days, the prune could delete the lock file while it was held. On POSIX the session's next hook then created a new file at the same path, locked it at once and ran beside the holder. That brings back the parallel-hooks race #156 closed. On Windows the delete fails while the file is open.This PR makes
runtouch the lock file right after it takes the lock, before_pruneruns. The file's age is then the time since the session's last hook, which is whatIDLE_Sis meant to measure. A session that has run no hook for 2 days still loses its file, as before.The test is in
tests/test_hook_queue.py, next to the existing prune test. It ages a session's lock file pastIDLE_Sand runs a hook throughhookqueue.run. Inside the handler, a second hook tries to take the same session's lock. The test checks that the second hook does not get it, and that the lock file's mtime is fresh afterwards.How it was produced: Claude Code, an AI coding agent, found the bug by reading
hookqueue.pyand reproduced it in a Linux container. It also wrote the fix and the test. I directed the work.What was checked, on
mainat81e32e5:python:3.12), the second hook gets the lock:[True] == [False]. On Windows 11 the delete fails while the file is open, so the test fails on the mtime check instead.tests/test_hook_queue.pypasses on Linux and on Windows.testsrun on Windows 11, Python 3.10:python -m pytest testsreports 888 passed, 24 skipped and 0 failed. The skips need tools this machine does not have. I did not runexperiments/tests.🤖 Generated with Claude Code