Restoring a session whilst using nvim-tree causes invalid buffer error

[akinsho]

Describe the bug
When loading up nvim with https://github.com/kyazdani42/nvim-tree.lua with a session immediately loaded gitsigns errors reporting.

Error executing vim.schedule lua callback: ...acker/start/plenary.nvim/lua/plenary/asy
nc_lib/async.lua:14: The coroutine failed with this message: ...im/site/pack/packer/st
art/gitsigns.nvim/lua/gitsigns.lua:542: Invalid buffer id: 2

To Reproduce

init.lua:

-- Presuming both plugins have been installed as vim packages
vim.cmd("packadd gitsigns.nvim")
vim.cmd("packadd nvim-tree.lua")

require("gitsigns").setup()

Steps to reproduce the behavior:

1. Open a nvim inside a directory
2. Open some files, then mksession
3. Close nvim and reopen via nvim -u minimal.lua -S
4. see error message

Observed output
Error messages, logs, etc

output of :lua require('gitsigns').debug_messages().

setup_highlight: Deriving GitSignsDelete from DiffDelete
setup_highlight: Deriving GitSignsAdd from DiffAdd
setup_highlight: Deriving GitSignsChange from DiffChange
run_job: git --no-pager --version
attach(2): Attaching

Screenshots
If applicable, add screenshots to help explain your problem or to capture error messages.

Additional context
System: Ubuntu 20.10
Neovim version:

Error executing vim.schedule lua callback: ...acker/start/plenary.nvim/lua/plenary/async_lib/async.lua:14: The coroutine failed with this message: ...im/site/pack/packer/star
t/gitsigns.nvim/lua/gitsigns.lua:542: Invalid buffer id: 2Error executing vim.schedule lua callback: ...acker/start/plenary.nvim/lua/plenary/asy
nc_lib/async.lua:14: The coroutine failed with this message: ...im/site/pack/packer/st
art/gitsigns.nvim/lua/gitsigns.lua:542: Invalid buffer id: 2
setup_highlight: Deriving GitSignsDelete from DiffDelete
setup_highlight: Deriving GitSignsAdd from DiffAdd
setup_highlight: Deriving GitSignsChange from DiffChange
run_job: git --no-pager --version
attach(2): Attaching
:version
NVIM v0.5.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-PEGyaz/neovim-0.5.0+ub
untu2+git202104182337-66f9dd3c6-d569569c9=. -fstack-protector-strong -Wformat -Werror=f
ormat-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedan
tic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissin
g-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagno
stics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOA
T32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/build/neovim-PEGyaz/neovim-0.5.0+ubu
ntu2+git202104182337-66f9dd3c6-d569569c9/build/config -I/build/neovim-PEGyaz/neovim-0.5
.0+ubuntu2+git202104182337-66f9dd3c6-d569569c9/src -I/build/neovim-PEGyaz/neovim-0.5.0+
ubuntu2+git202104182337-66f9dd3c6-d569569c9/.deps/usr/include -I/usr/include -I/build/n
eovim-PEGyaz/neovim-0.5.0+ubuntu2+git202104182337-66f9dd3c6-d569569c9/build/src/nvim/au
to -I/build/neovim-PEGyaz/neovim-0.5.0+ubuntu2+git202104182337-66f9dd3c6-d569569c9/buil
d/include
Compiled by buildd@lcy01-amd64-029

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

[Shatur]

Can confirm. I use vim.schedule as a workaround.

[akinsho]

For a bit more context if needed, this issue seems to be very related to nvim-tree's behaviour, it does some stuff with buffers being created and sometimes destroyed when a session is loaded that might be what is tripping up gitsigns but in my mind gitsigns should be excluding special buffers although I guess nvim tree might not have marked it's buffer in any way that makes it clear that it is special 🤔 ?

I've switched to lazy loading nvim tree and that seems to at least avoid the issue 😅

[lewis6991]

Funilly enough the error happens during gitsigns buffer validation checks:

local attach = async(function(cbuf: integer)
  await(scheduler())
  cbuf = cbuf or current_buf()
  if cache[cbuf] then
    dprint('Already attached', cbuf, 'attach')
    return
  end
  dprint('Attaching', cbuf, 'attach')

  if api.nvim_buf_line_count(cbuf) > config.max_file_length then -- ERROR HERE
    dprint('Exceeds max_file_length', cbuf, 'attach')
    return
  end

  if api.nvim_buf_get_option(cbuf, 'buftype') ~= '' then
    dprint('Non-normal buffer', cbuf, 'attach')
    return
  end

I guess we need to tweak the ordering and maybe add another check.

[carlitux]

I am totally assuming...

Also, it is related with maybe closed floating windows, not sure if nvim-tree use floating window.

The source that calls as I saw https://github.com/lewis6991/gitsigns.nvim/blob/main/lua/gitsigns.lua#L777 list all buffers but on async, the buffer does not exist later.

  for _, buf in ipairs(api.nvim_list_bufs()) do
      if api.nvim_buf_is_valid(buf) and
         api.nvim_buf_is_loaded(buf) and
         api.nvim_buf_get_name(buf) ~= '' then
         await(attach(buf))
         await(scheduler())
      end
   end

[lewis6991]

I did a speculative fix by just checking the buffer is loaded. Let me know if this fixes the issue.

[akinsho]

Just gave it a shot and still seems to persist unfortunately

[carlitux]

still having the issue

[lewis6991]

Arggh, there was a missing not which rendered the plugin useless. Should be ok now.

[carlitux]

I am still having the issue, after reading the docs looks like it is related to deleted buffers as unloaded buffer returns 0 nvim_buf_line_count

nvim_list_bufs()                                            *nvim_list_bufs()*
                Gets the current list of buffer handles

                Includes unlisted (unloaded/deleted) buffers, like `:ls!` .
                Use |nvim_buf_is_loaded()| to check if a buffer is loaded.

                Return: ~
                    List of buffer handles

nvim_buf_line_count({buffer})                          *nvim_buf_line_count()*
                Gets the buffer line count

                Parameters: ~
                    {buffer}  Buffer handle, or 0 for current buffer

                Return: ~
                    Line count, or 0 for unloaded buffer. |api-buffer|

[lewis6991]

We shouldn't reach nvim_buf_line_count in the latest change. I forgot to invert the condition on the check.

[carlitux]

it is working now! thanks

[akinsho]

Just tried it and it's also solved on my end 👍🏿 I can close this out now?