You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #1801 (fixed in #1814). Same shape, lower risk — filed so it isn't rediscovered from scratch if it ever does bite.
Context
#1801 was smoke:tui failing intermittently with ENOTEMPTY: done() sent SIGTERM and then synchronously rmSync'd the work dir, without waiting for the child to exit. scripts/pack-and-verify.mjs has the same kill-then-remove pattern in two places.
The two sites
scripts/pack-and-verify.mjs:330 (success path) — the closer analogue. verifyWeb()'s finally { stop() } sends SIGTERM (line 377-380), control returns to the main flow, and rmSync(work, …) runs immediately with nothing awaiting the child's exit.
scripts/pack-and-verify.mjs:74-78 (fail()) — kills webChild and rmSyncs workDir back to back.
Why this is low priority, not a live flake
Unlike smoke-tui, the --web child's HOME is not redirected into the work dir — work is only its cwd and the location of the installed package it reads. In smoke:tui intermittently fails with ENOTEMPTY cleaning its temp dir #1801 the work dir wasHOME, so the Ink app was actively writing config/storage into the directory being deleted, which is what made the race fire. Nothing here writes into work on shutdown, and on macOS a live cwd doesn't block removal.
fail() runs only when the verify has already failed and is exiting 1, so an ENOTEMPTY there cannot manufacture a spurious red — worst case it masks the real failure message with an rmSync stack and skips the "tarball retained at …" hint.
Apply the #1814 treatment to stop(): make it await the child's exit event (escalating SIGTERM → SIGKILL after a grace period, then proceeding anyway with a warning) before the caller removes work, and wrap the rmSync calls so a leftover temp dir warns instead of throwing over the real failure message. See scripts/smoke-tui.mjs after #1814 for the pattern.
Follow-up to #1801 (fixed in #1814). Same shape, lower risk — filed so it isn't rediscovered from scratch if it ever does bite.
Context
#1801 was
smoke:tuifailing intermittently withENOTEMPTY:done()sentSIGTERMand then synchronouslyrmSync'd the work dir, without waiting for the child to exit.scripts/pack-and-verify.mjshas the same kill-then-remove pattern in two places.The two sites
scripts/pack-and-verify.mjs:330(success path) — the closer analogue.verifyWeb()'sfinally { stop() }sendsSIGTERM(line 377-380), control returns to the main flow, andrmSync(work, …)runs immediately with nothing awaiting the child'sexit.scripts/pack-and-verify.mjs:74-78(fail()) — killswebChildandrmSyncsworkDirback to back.Why this is low priority, not a live flake
smoke-tui, the--webchild'sHOMEis not redirected into the work dir —workis only its cwd and the location of the installed package it reads. In smoke:tui intermittently fails with ENOTEMPTY cleaning its temp dir #1801 the work dir wasHOME, so the Ink app was actively writing config/storage into the directory being deleted, which is what made the race fire. Nothing here writes intoworkon shutdown, and on macOS a live cwd doesn't block removal.fail()runs only when the verify has already failed and is exiting 1, so anENOTEMPTYthere cannot manufacture a spurious red — worst case it masks the real failure message with anrmSyncstack and skips the "tarball retained at …" hint.pack:verifyis not in the local pre-push gate. It runs in CI on the publish path only (.github/workflows/main.yml:155), so a flake would be rare and loud rather than the learned-to-re-run red smoke:tui intermittently fails with ENOTEMPTY cleaning its temp dir #1801 became.Suggested fix
Apply the #1814 treatment to
stop(): make it await the child'sexitevent (escalatingSIGTERM→SIGKILLafter a grace period, then proceeding anyway with a warning) before the caller removeswork, and wrap thermSynccalls so a leftover temp dir warns instead of throwing over the real failure message. Seescripts/smoke-tui.mjsafter #1814 for the pattern.