bug: Error when quickly previewing files with semantic tokens LSP capabilities.

[deeedob]

Did you check the docs and existing issues?

• [X] I have read the docs
• [X] I have searched the existing issues

Neovim version (nvim -v)

NVIM v0.11.0-dev-189+g78d3f4742

Operating system/version

ndeavourOS Linux x86_64

Describe the bug

I observed that when I preview files in a directory with a LSP that provides semanticTokens I get bombarded with such errors:

Error executing vim.schedule lua callback: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:102: Invalid buffer id: 32
stack traceback:
	[builtin#36]: at 0x5a9e035cf470
	...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: in function 'handler'
	/usr/local/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>
Error executing vim.schedule lua callback: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:102: Invalid buffer id: 33
stack traceback:
	[builtin#36]: at 0x5a9e035cf470
	...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: in function 'handler'
	/usr/local/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

when I step through the files very slowly (and let the semantic tokens finish loading) I don't get such errors. Same as when I disable them from the LSP: server_capabilities = { semanticTokensProvider = vim.NIL } .

I noticed it with the clangd language server.

What is the severity of this bug?

breaking (some functionality is broken)

Steps To Reproduce

1. Use a LSP which provides semantic tokens. I used clangd
2. Open oil and preview the files (which the lsp recognizes) very quickly so that semantic tokens cannot finish loading

Expected Behavior

No error.

Directory structure

No response

Repro

-- Sorry, I don't have time for this. Either the issue is clear and easily reproducible with a LSP that supports semantic tokens or you can close it. I just want to report the issue

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  {
        "stevearc/oil.nvim",
        config = function()
            require("oil").setup({
              -- add any needed settings here
            })
        end,
  },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Did you check the bug with a clean config?

• [X] I have confirmed that the bug reproduces with nvim -u repro.lua using the repro.lua file above.