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
perf: Use a more aggressive retry loop for recursiveDelete (#84444)
**Update:** This also fixes a bug pointed out by Graphite where the deletion function could hang forever because the `t` variable used for tracking attempts wasn't properly incremented.
---
https://vercel.slack.com/archives/C04KC8A53T7/p1759360239193629
This is a critical path for `next dev` and `next build` initialization.
On Windows, it's quite common to get an error while trying to recursively delete directories for one of two reasons:
**Temporarily open files:**
1. You open the directory.
2. The user's AV detects the directory as opened and quickly scans the files in that directory.
3. You try to delete a file, but on Windows, files cannot be deleted when open.
**Deletion is not instant/atomic:** It can take some time after deleting files for the directory to become empty.
For this reason, we perform two retries with a 100ms delay after the first attempt and a 200ms delay after the second attempt.
* Node does not use retries by default, but has an option to do so with a `100ms * attemptNumber` (linear backoff) delay, similar to what we do: https://github.com/nodejs/node/blob/b5638e1765d3d1241d07457e767f27e3ee6b9dd2/lib/internal/fs/utils.js#L774-L779
* Node used to use 3 retries by default, but that was changed in v14: nodejs/node@7e85f06
* Rust tries to delete 64 times in a loop without sleeping, but with a call to `thread::yield_now`: https://github.com/rust-lang/rust/blob/4da69dfff1929cc79872b3d05ab7112d84753dba/library/std/src/sys/fs/windows/remove_dir_all.rs#L154-L171
In the vein of reducing time spent sleeping in the critical initialization path (@timneutkens), I think we should be more aggressive, I'm thinking using a 10ms delay (arbitrary number), but with an exponential backoff, so that we still retry over the same 300ms period as we currently do? Thoughts?
The difficulty is that this is on Windows, so it's hard for me to get good numbers about what impact this would have (if any).
0 commit comments