diff options
| author | David Balatero <dbalatero@gmail.com> | 2026-05-05 13:57:56 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-05-05 13:57:56 -0400 |
| commit | 19a2ef5afaf2e6c78dfb6302457116709dc49cc0 (patch) | |
| tree | 2875e57bb0535596d34168c76810911a332710cc /runtime/lua/vim/provider/python.lua | |
| parent | 78111e5371f50f42d3999b2e475953d9c8a30c27 (diff) | |
| download | rneovim-19a2ef5afaf2e6c78dfb6302457116709dc49cc0.tar.gz rneovim-19a2ef5afaf2e6c78dfb6302457116709dc49cc0.tar.bz2 rneovim-19a2ef5afaf2e6c78dfb6302457116709dc49cc0.zip | |
test: unreliable pack_spec.after_each: "EBUSY: resource busy or locked" #39606
Problem:
`EBUSY` during cleanup:
Windows CI can intermittently fail `pack_spec.lua` with `EBUSY` while removing
`site/pack/core/opt/plugindirs`.
This can happen because:
- the test Nvim session may still be alive when `after_each()` removes the pack
directory
- Windows does not allow removing a directory while another process still has an
open handle below it
- startup-time `vim.pack.add()` performs a real `git clone`, so process and file
handle release timing can vary on slower runners
Startup timeout:
The startup tests can also fail before cleanup because they wait for `_G.done`
with a fixed timeout. That timeout includes the time needed for startup to run
`vim.pack.add()` and finish the local clone.
Solution:
Close before cleanup:
Capture the pack, lockfile, and log paths while the test Nvim session is still
available, then call `n.check_close()` before removing the pack directory.
Extend Windows startup wait:
Increase the `_G.done` retry budget only on Windows so startup-time
`vim.pack.add()` has more time to finish on slower CI runners.
Diffstat (limited to 'runtime/lua/vim/provider/python.lua')
0 files changed, 0 insertions, 0 deletions