rushstack icon indicating copy to clipboard operation
rushstack copied to clipboard

[heft] Windows support regression

Open philippe-wm opened this issue 3 months ago • 6 comments

Summary

After upgrading Heft, rush build on Windows started failing with an IO error (couldn't repro with rushx build) happening with random projects, e.g. not consistently the same packages, which seems to indicate that it is a race condition. However it does always happen with /temp/build.

Repro steps

We upgraded Heft and related plugins:

-    "@rushstack/heft": "^0.68.2",
+    "@rushstack/heft": "0.74.5",

Expected result:

rush build still works on all machines

Actual result:

rush build fails on Windows with an IO error

Details

Rig changes:

Image

Build error:

A few projects fail to build with this error:

--[ FAILURE: @wbd/beam-dom-extensions (build) ]--------------[ 2.17 seconds ]--
...
[build:clean] Starting clean
[build:clean] Deleted folder "C:/Users/name/monorepo-root/libraries/beam-dom-extensions/dist".
[build:clean] Deleted folder "C:/Users/name/monorepo-root/libraries/beam-dom-extensions/temp/build".
EPERM: operation not permitted, rmdir 'C:\name\monorepo-root\libraries\beam-dom-extensions\temp\build'

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question Answer
@rushstack/heft version? 0.74.5
Operating system? Windows
Would you consider contributing a PR? Yes (with solid pointers)
Node.js version (node -v)? 20.18.1

philippe-wm avatar Sep 23 '25 13:09 philippe-wm

If you run rush --debug build do you get a stack from that? Since you mention rushx build is working fine that suggests this is in the deletion layer prior to restoring build cache entries.

dmichon-msft avatar Sep 29 '25 20:09 dmichon-msft

I ran it with --verbose as --debug didn't seem valid.

Edited the description: error is random and logs don't tell much.

philippe-wm avatar Oct 01 '25 10:10 philippe-wm

Could it be that the clean task isn't able to finish the clean before the build step gets a hold of the /temp/build folder?

philippe-wm avatar Oct 01 '25 10:10 philippe-wm

@philippe-wm - That's unlikely. All async filesystem operations should be settled before Heft moves on to a later phases.

Is it possible that something like Windows Defender has a lock on files in your repo?

iclanton avatar Oct 06 '25 18:10 iclanton

@iclanton we see that both in CI (I doubt it runs Defender) and with a Windows Laptop. Also we don't see the issue with the older Heft version.

philippe-wm avatar Oct 10 '25 14:10 philippe-wm

Disabling parallelism doesn't solve the issue.

philippe-wm avatar Oct 10 '25 15:10 philippe-wm