vp migrate hangs indefinitely (0% CPU) when the project's pinned pnpm deadlocks during install

Summary

vp migrate can hang indefinitely at 0% CPU (no output, no progress, no timeout) on some projects. The hang is in the dependency install that migrate spawns: the project's pinned pnpm 9.x deadlocks on an internal worker pipe. Because vp migrate has no timeout or hang detection, the command never returns and must be killed manually.

Discovered while smoke-testing the v0.2.2 prerelease (PR #2016, registry-bridge commit 1d7ba811f0e456640b0e761e8e8acf77d1ad3251) across ~64 real-world projects: 2 of them hang every time, the other ~62 migrate fine.

Affected projects (100% reproducible)

Project	Pinned pnpm	Node
anywidget	[email protected]	24.18.0
vitepress-carbon	[email protected]	22.18.0 (.node-version)

Both are pnpm monorepos. ~62 other projects in the same run (mostly newer pnpm) migrated successfully through the same registry bridge, so this is specific to these projects' resolution + their old pinned pnpm.

Symptom

vp migrate prints nothing after startup and never returns:

Running vp migrate in /Users/.../anywidget
        <-- hangs here forever; killed after 20 min every time -->

• The vp process and its node/pnpm children all sit at 0.0% CPU (idle deadlock, not a busy loop).
• Not a stdin prompt: reproduces identically with stdin redirected from /dev/null.
• Not concurrency: reproduces when run solo with nothing else installing.

Root-cause evidence

The hung process is the install that migrate spawns:

node .../pkg-pr-new/<sha>/package_manager/pnpm/9.10.0/pnpm/bin/pnpm.cjs install --no-frozen-lockfile

Stack sample of the hung node/pnpm main thread (sample <pid>):

node::SpinEventLoopInternal
  uv_run
    uv__io_poll
      kevent   <-- main thread parked in the event loop waiting on an fd

lsof of the hung process shows no TCP/network connections — only internal PIPE fds:

node  <pid>  ...   4   PIPE 0x...->0x...
node  <pid>  ...   5   PIPE 0x...->0x...
node  <pid>  ...  12   PIPE 0x...->0x...
node  <pid>  ...  13   PIPE 0x...->0x...

So it is not stalled on the registry/network. pnpm's main process is blocked in the event loop waiting on an internal worker pipe that never signals, i.e. an internal pnpm worker-IPC deadlock (same class as the pnpm 11.0.6 "hangs after Done" bug that was fixed in 11.5.1, but here on pnpm 9.x).

Reproduction

# via the pkg.pr.new bridge migrate helper
ALLOW_DIRTY=1 .github/scripts/test-pkg-pr-new-migrate.sh \
  1d7ba811f0e456640b0e761e8e8acf77d1ad3251 /path/to/anywidget --no-interactive
# ...or plainly: cd anywidget && vp migrate
# hangs at "Running vp migrate ..." with 0% CPU; sample/lsof the pnpm child as above.

Impact

• vp migrate never completing is a poor failure mode: no error, no timeout, silent 0%-CPU hang; a CI or a user waits forever.
• In an automated fleet run it also leaves orphaned hung pnpm processes behind (observed several, up to 1h+ old) that must be reaped manually.

Suggested directions

1. Add a timeout / hang detection to the install step of vp migrate so it fails loudly (with the pnpm command + partial output) instead of hanging silently forever. This alone converts the worst part (silent infinite hang) into an actionable error.
2. Consider running the migrate install with vp's managed/bundled pnpm (newer) rather than the project's old pinned [email protected] that deadlocks, or expose a flag to opt into that.
3. Investigate the underlying pnpm 9.x worker-pipe deadlock on these two projects' graphs (likely reproducible with a plain [email protected] install on anywidget).

Found during the v0.2.2 real-world test; see https://github.com/voidzero-dev/vite-plus/pull/2016 for the prerelease build under test.