ignore cache write EPERM errors on Windows#4685
Conversation
if we're reasonably sure they came from a cross-process race condition
|
@jeanlauliac Thoughts on this? Is it dangerous to ignore the failure? |
| * On Windows, renames are not atomic, leading to EPERM exceptions when two | ||
| * processes attempt to rename to the same target file at the same time. | ||
| * If the target file exists we can be reasonably sure another process has | ||
| * legitimately won a cache write race and ignore the error. |
There was a problem hiding this comment.
Can you mention #4444 in the comment so that we'll hopefully come back later and revert this when it's not necessary?
jeanlauliac
left a comment
jeanlauliac
left a comment
There was a problem hiding this comment.
I think that's reasonnable!
|
Tests are failing for "test-node-8" though, can you investigate and/or rebase the changeset so that we make sure it's all good? Thank you! |
|
I think we can merge this, the node 8 issue was fixed separately. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
5 participants
Summary
Ignore cache write EPERM errors on Windows if we're reasonably sure they came from a cross-process race condition
Test plan
Race conditions are hard to test for, but I was able to verify this patch resolved the cache write errors I was seeing on Windows as part of a Jest 21 upgrade by logging out errors caught by this check and seeing several hits (alongside passing tests).
This is ideally a temporary fix for #4444. It seems the real fix is upstream at isaacs/node-graceful-fs#119, but in the meantime, this will unblock Windows users trying to upgrade to Jest 21 or later.