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
we use a monorepo and depend on multiple electron versions (some are the same and some are different). Lately we got hit by a race condition during yarn install on Windows. The error message is:
I went down the rabbit hole and created a reproducer for the behaviour. The working assumption was that due to hoisting we ended up with the same electron version in multiple locations of the workspace tree. Those then postinstall in parallel which causes issues.
With that reproducer I triggered the error after a few cycles of:
A parallel capture of all syscalls with procmon showed that:
all three node processes first checked for a cached version of electron 13
all three downloaded electron into a temporary file
one finished first and moved the temporary file to the destination (move with overwrite)
The two remaining processes wanted to open the destination file and got a "DELETE PENDING" syscall response
Would you be able to implement locking within @electron/get to avoid the race condition and also avoid downloading electron multiple times? Or just add a retry loop?
Also yarn isn't innocent here. IMHO it should not trigger postinstall scripts for the same version of a package concurrently to avoid this type of issue. But damage is done and maybe @electron/get could be made a little bit smarter to deal with the parallel invocvations.
Thanks,
Gregor
The text was updated successfully, but these errors were encountered:
Hello,
we use a monorepo and depend on multiple electron versions (some are the same and some are different). Lately we got hit by a race condition during
yarn install
on Windows. The error message is:I went down the rabbit hole and created a reproducer for the behaviour. The working assumption was that due to hoisting we ended up with the same electron version in multiple locations of the workspace tree. Those then postinstall in parallel which causes issues.
With that reproducer I triggered the error after a few cycles of:
A parallel capture of all syscalls with procmon showed that:
Would you be able to implement locking within
@electron/get
to avoid the race condition and also avoid downloading electron multiple times? Or just add a retry loop?Also yarn isn't innocent here. IMHO it should not trigger postinstall scripts for the same version of a package concurrently to avoid this type of issue. But damage is done and maybe
@electron/get
could be made a little bit smarter to deal with the parallel invocvations.Thanks,
Gregor
The text was updated successfully, but these errors were encountered: