Repository navigation
fix(hooks): hooks-run exits once its line is written (#167) - #177
Merged
Merged
Conversation
The pre-commit guard runs inside `git commit`. On the allowed path it printed its line and returned, waiting for the process to end on its own; the blocked path already called process.exit(1). On the Windows nightly (Node 22, 10-18 and 10-20) the allowed path printed "✓ faf: context 6% → 21% (+15)" and `git commit` then hit the 120 s child limit: the #167 shape inside a hook. - cli.ts: after hooksRun returns, exit 0 once stdout and stderr have flushed, with a 2 s backstop timer (unref'd). hooksRun itself is unchanged, so the in-process tests still call it directly. - hooks.test.ts: a git commit that hits its limit now reads "hung child process (#167)"; temp folders get a name ("case") instead of "undefined". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
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
1 participant
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.
What
faf hooks-run(the pre-commit context guard) now exits as soon as its line is written, on the path that allows the commit. The blocked path already exits (process.exit(1)).Why
The guard runs inside
git commit. On the allowed path it printed its line and then waited for the process to end on its own. The Windows nightly (Node 22, the gating job) failed twice on the same test,hooks.test.ts:233"STRICT lets an improving commit through":It's all or nothing: about 1 s, or the nightly's 120 s child limit. The failing runs printed
✓ faf: context 6% → 21% (+15)(the hook had allowed the commit), thengit committimed out withETIMEDOUT, and the temp folder was left locked. That is the #167 shape (a child finishes and never exits), inside a commit hook, where a user would feel it.This doesn't find #167's cause. It takes the wait out of the one place a hang would freeze a user's commit.
Changes
src/cli.ts: afterhooksRunreturns, exit 0 once stdout and stderr have flushed, with a 2 s backstop timer (unref'd). Every path that returns there allows the commit.hooksRunitself is unchanged, so the in-process tests still call it directly.tests/wjttc/hooks.test.ts: agit committhat hits its limit now readshung child process (#167), like the other spawned-child tests. Temp folders get the namecaseinstead ofundefined.Checked (macOS, Node 24, bun)
npx tsc --noEmitclean;npm run lint: 0 errors,src/cli.tswarnings unchanged (2 before, 2 after).npm test: 2,218 pass, 0 fail (3 build-artifact tests needdist/; they pass afternpm run build).✓ faf: context 3% → 6% (+3)and exits 0; a regression under--strictprints the⚠line and exits 1.PR CI: all green. The first Windows Node 22 attempt failed in
owner-rule-r7BRAKE R7-3 (bun faf compile/bun faf taf --outputhung: the 10-19 nightly shape, a code path this PR doesn't touch); the re-run passed. The hooks commit tests are nightly-only, so the PR job skips them.The proof is the Windows nightly: this test should stop failing at 120 s on Node 22.
Refs #167
🤖 Generated with Claude Code