test(snapshots): bound the PTY spawn with the per-step timeout#2102
Conversation
✅ Deploy Preview for viteplus-preview canceled.
|
How to use the Graphite Merge QueueAdd the label auto-merge to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e16a7cf38f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
fengmk2
force-pushed
the
fix/pty-spawn-timeout
branch
from
e16a7cf to
a7957d7
Compare
fengmk2
changed the base branch from
graphite-base/2102
to
fix/redact-scaffold-pm-version
|
@codex review |
graphite-app
Bot
changed the base branch from
fix/redact-scaffold-pm-version
to
graphite-base/2102
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
graphite-app
Bot
force-pushed
the
graphite-base/2102
branch
from
0f0a211 to
ab7f35b
Compare
graphite-app
Bot
force-pushed
the
fix/pty-spawn-timeout
branch
from
512c75f to
122bd41
Compare
graphite-app
Bot
force-pushed
the
fix/pty-spawn-timeout
branch
from
122bd41 to
f1f780b
Compare
The per-step timeout only wrapped the interaction phase (rx.recv_timeout): TestTerminal::spawn (openpty + fork/exec the child into the PTY) ran synchronously before it. On runners where that spawn can block (the Linux analog of the ConPTY blocking that keeps the Windows snapshot job on a GitHub-hosted runner), a wedged spawn was unbounded, and because the parallel execution gate holds the case's lease, it stalled the whole suite (6h job default, no step log). Run the spawn on a helper thread bounded by the same per-step timeout: a wedged spawn now fails that one case (like any other step timeout) and the suite proceeds. Success path is unchanged (verified against the interactive picker cases). The helper thread is abandoned on timeout, which is fine for a dev-only test binary that exits when the run ends.
If the spawn wait times out and the helper thread's TestTerminal::spawn still succeeds afterwards, the send fails and the terminal was dropped without killing its child (TestTerminal has no Drop that kills). Handle the SendError and kill the child so a slow-but-live command cannot keep running after the case has already failed.
fengmk2
force-pushed
the
fix/pty-spawn-timeout
branch
from
f1f780b to
504379f
Compare
|
You can consider writing the timeout in the snapshot like: https://github.com/voidzero-dev/vite-task/blob/cda404d1f12cb9fa4a73f93bd863a636ebc4dcd9/crates/vite_task_bin/tests/e2e_snapshots/main.rs#L584 This way the previous outputs will be naturally written in the snapshot. |
The recurring Linux snapshot hang survives #2102's spawn bound (a run that contained the bound still wedged for the full 10-min step timeout), so the wedge is at a different, still-unbounded point (or cumulative create-test timeouts around the ctrl-c case). Add snap_trace (gated on VP_SNAP_TRACE=1), writing START/phase/END lines straight to fd 2 so they survive libtest capture and reach the CI log even when the step is killed by its timeout. A step that logs START without END is the wedged one, and the phase markers (spawn dispatched / spawned / waiting for exit) localize within it. Enable it on the Linux PTY CI step; off by default everywhere else.
The recurring Linux snapshot hang survives #2102's spawn bound (a run that contained the bound still wedged for the full 10-min step timeout), so the wedge is at a different, still-unbounded point (or cumulative create-test timeouts around the ctrl-c case). Add snap_trace (gated on VP_SNAP_TRACE=1), writing START/phase/END lines straight to fd 2 so they survive libtest capture and reach the CI log even when the step is killed by its timeout. A step that logs START without END is the wedged one, and the phase markers (spawn dispatched / spawned / waiting for exit) localize within it. Enable it on the Linux PTY CI step; off by default everywhere else.
2 participants
The per-step timeout only wrapped the interaction phase (
rx.recv_timeout):TestTerminal::spawn(openpty + fork/exec the child into the PTY) ran synchronously before it. On runners where that spawn can block (the Linux analog of the ConPTY blocking that keeps the Windows snapshot job on a GitHub-hosted runner), a wedged spawn was unbounded, and because the parallel execution gate holds the case's lease, it stalled the whole suite (6h job default, no step log).Run the spawn on a helper thread bounded by the same per-step timeout: a wedged spawn now fails that one case, like any other step timeout, and the suite proceeds. The success path is unchanged (verified against the interactive picker cases). The abandoned helper thread is fine for a dev-only test binary that exits when the run ends.
What a wedged spawn looks like now
Forcing the spawn to block (the failure this fixes), the case now fails at its per-step timeout instead of hanging the run:
(
2sis a shortened demo timeout; the real per-step default is 50s. The other cases keep running and the step log is preserved, versus the old behavior where this same block hung the whole step until the 6h job default with no log.)