'Invalid buffer id' when navigating too fast upwards

[andrewferrier-ibm]

(I am not sure if this is related to #12. The errors are similar but not the same so I thought I'd keep it separate for clarity).

I see this style of error quite a lot when navigating around using dirbuf.nvim:

Error executing vim.schedule lua callback: ...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:14: The coroutine failed with this mess
age: ...r/neovim/0.6.1/share/nvim/runtime/lua/vim/diagnostic.lua:51: Invalid buffer id: 4
stack traceback:
        [C]: in function 'error'
        ...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:14: in function 'callback_or_next'
        ...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:40: in function <...ck/packer/start/plenary.nvim/lua/plenary/async/async.l
ua:39>

The buffer id itself varies, but otherwise the error is the same stacktrace.

The strange thing is that whether it appears seems to depend on how fast I navigate around! I can recreate it like this:

1. Open NeoVim with any file: nvim ~/.some/relatively/deeply/nested/file
2. Navigate upwards rapidly by pressing - several times in quick sequence. 2-3 times seems to produce the error.

If I deliberately slow down (e.g. leave a delay of >0.5s between - keypresses), the error does not occur.

Because I tend to move around quite fast, this gets annoying after a while!

I know this sounds strange, but I can reproduce it fairly reliably on my system. I haven't yet tried to reproduce it with a minimal configuration but happy to try that if it would help.

[andrewferrier]

In case this helps, I have done a git bisect, since this problem didn't occur until recently. Looks like this problem was introduced by this commit

commit 7cdcd19324c93b90e7c2bf35e59680c174abac62
Author: Eli W. Hunter <elihunter173@gmail.com>
Date:   Thu Jan 27 21:46:06 2022 -0500

    Set bufhidden=wipe

 lua/dirbuf.lua | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

If I checkout the commit before this, the problem disappears.

[elihunter173]

This is interesting since the error message is coming from plenary.nvim's async.lua, but Dirbuf doesn't use plenary. I suspect the issue is there is some autocommand or background task running when a dirbuf buffer is being opened / is open. So when you navigate quickly, the directory buffers are getting deleted before that background task finishes running (since bufhidden=wipe deletes buffers when you hide).

Is there any plugin or part of your config that you would suspect is doing something like this? I can't seem to replicate this with a minimal config or my personal config

[andrewferrier]

Apologies, this was totally my fault, and you're quite right, it's not in dirbuf - the issue was in null-ls, which uses plenary. Just in case others come across the same issue:

I have a custom null_ls source which applies to almost every buffer which checks for trailing spaces. It had a list of disabled_filetypes which included d, the filetype that vinegar seems to use. However, when I switched to dirbuf, I obviously forgot to change this over. Adding "dirbuf" to the disabled_filetypes list for that source fixed it.

Thanks again for the clues and sorry for taking up your time on an issue which wasn't dirbuf's!

[andrewferrier]

I think you can close this issue, FWIW :)

[elihunter173]

Happy to help!