🤖 tests: loop-test runner signal edge cases (deferred from #7208)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- bun, typescript
Research direction
Start with scripts/perf/loopTestBaseline.ts and trace how signal handling interacts with measure, runPool, and stopChildren(). The issue reports two deferred edge cases but says the first race was not reproduced and the second is intentionally left as is. Pick up only if a stopped run leaves a record, scratch directory, or worktree behind; done means reproducing that leftover and fixing it without disrupting cleanup.
Written by the indexing model from the issue text.
Description
Two edge cases in the loop-test runner's signal handling (scripts/perf/loopTestBaseline.ts). The advisor of the #7208 fix stack (#7264, #7265) raised them. Both are deferred from #7208 with the reasons below.
- With
--runs 1, a signal during the last run letsmeasureresolve, so main can write a record that holds the killed run. I triedassert(!stopping)afterrunPoolplus a fixture test. The test also passed without the fix: in Bun 1.4.3 the signal handler reachesprocess.exitbefore main writes. I could not show the race, so I did not ship the fix. - A second SIGINT or SIGTERM while
stopChildren()waits uses the default handler (process.once). It kills the runner and leaves the children, the scratch dir and the base worktree behind. A user who signals twice asks for an immediate stop, so this stays as is unless it causes trouble.
Owner: the phase 1 builder. Trigger: a leftover record, scratch dir or worktree after a stopped run.
Refs #7208, #7255
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $62.13
- Dominant language
- TypeScript
- Stars
- 2.1k
- Forks
- 140
- Avg merge
- 4h 57m
- Merged PRs (30d)
- 946
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
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 coder/xum
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
🤖 fix: a Daytona connection test started before a settings save can show the old key as connectedOpen
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
MoonshotAI/kimi-code#4398 ·
Maintainers usually reply within 1 day
-
Xiaomi Mimo语音识别服务异常Openpending triage
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
package-lock.json : les binaires natifs macOS et Linux de unrs-resolver ont disparu depuis #1823Openbug dependencies
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AxaFrance/design-system#2064 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100