fix(core): don't hang when workspace contains a named pipe

[leosvelperez]

Current Behavior

If a workspace contains a named pipe (FIFO) — e.g. created via mkfifo — any nx command that walks the workspace (e.g. nx show projects) hangs forever with no output. The native file hasher calls std::fs::read on the FIFO, which blocks indefinitely waiting for a writer.

Expected Behavior

Special files that cannot be meaningfully hashed as workspace content (FIFOs, sockets, block/char devices) are skipped by the native walker, so nx commands complete normally.

Implementation Notes

• Filter added in nx_walker (parallel and wasm variants) so only regular files and symlinks are emitted as NxFile entries. Uses the metadata already fetched for mod_time, so there is no extra syscall cost.
• Symlinks are still emitted to preserve existing symlink-follow behavior via std::fs::read.
• Added a unix-only regression test (skips_named_pipes) that creates a FIFO with nix::unistd::mkfifo and asserts the walker skips it.

Related Issue(s)

Fixes #35228

[netlify]

✅ Deploy Preview for nx-docs ready!

Name	Link
🔨 Latest commit	993ce38
🔍 Latest deploy log	https://app.netlify.com/projects/nx-docs/deploys/69de4440f9c9b60008b3c75a
😎 Deploy Preview	https://deploy-preview-35289--nx-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[netlify]

✅ Deploy Preview for nx-dev ready!

Name	Link
🔨 Latest commit	993ce38
🔍 Latest deploy log	https://app.netlify.com/projects/nx-dev/deploys/69de4440c23d970008bf5495
😎 Deploy Preview	https://deploy-preview-35289--nx-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 993ce38

Command	Status	Duration	Result
nx affected --targets=lint,test,build,e2e,e2e-c...	✅ Succeeded	46m 24s	View ↗
nx run-many -t check-imports check-lock-files c...	✅ Succeeded	3s	View ↗
nx-cloud record -- pnpm nx conformance:check	✅ Succeeded	7s	View ↗
nx build workspace-plugin	✅ Succeeded	<1s	View ↗
nx-cloud record -- nx format:check	✅ Succeeded	<1s	View ↗
nx-cloud record -- nx sync:check	✅ Succeeded	<1s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-04-14 15:17:21 UTC

[nx-cloud]

Important

At least one additional CI pipeline execution has run since the conclusion below was written and it may no longer be applicable.

Nx Cloud has identified a possible root cause for your failed CI:

We identified that the maven-batch-runner:_package failure is a pre-existing environment issue unrelated to this PR's changes, which are confined to packages/nx/src/native/walker.rs. The same Maven shade plugin error ("error in opening zip file") was confirmed to exist on the master branch, indicating a build infrastructure problem that predates this PR.

No code changes were suggested for this issue.

Trigger a rerun:

View detailed reasoning on Nx Cloud ↗

🔔 Heads up, your workspace has pending recommendations ↗ to auto-apply fixes for similar failures.

_{🎓 Learn more about Self-Healing CI on nx.dev}

[huonw]

Thanks for fixing! 😄

Symlinks are still emitted to preserve existing symlink-follow behavior via std::fs::read.

I think a symlink could theoretically point to a non-hashable file, like a fifo; for example:

mkfifo test
ln -s test test2

I think test (FIFO) will be skipped, but I'm not sure about test2 (symlink to FIFO).

Is that handled?

(Other edge cases include symlinks to symlinks to symlinks to FIFO, etc.)