If bufnr is not the current buffer, then 0 is the wrong winid to be using. Could we either pass the winid as well, or check to see if the current buffer == bufnr and early return?

Incidentally, do you know where exactly the problem is arising? The only time I see this getting executed async is the vim.schedule call inside of InsertEnter, but the original bug report didn't mention anything about insert mode. Is the problem that something is switching the buffer right after entering insert mode? Or that something is causing you to enter insert mode as you switch buffers?

If bufnr is not the current buffer, then 0 is the wrong winid to be using. Could we either pass the winid as well, or check to see if the current buffer == bufnr and early return?

Sure, I'll try.

Incidentally, do you know where exactly the problem is arising? The only time I see this getting executed async is the vim.schedule call inside of InsertEnter, but the original bug report didn't mention anything about insert mode. Is the problem that something is switching the buffer right after entering insert mode? Or that something is causing you to enter insert mode as you switch buffers?

All the vim.schedule makes it hard to get a full stack trace. I added print(debug.traceback()) in a bunch of places to get the following results (note the line number may be off by a couple of lines).

.../oil.nvim/lua/oil/init.lua:1221: in function <.../oil.nvim/lua/oil/init.lua:1220>
stack traceback:
        .../oil/view.lua:536: in function 'initialize'
        .../oil.nvim/lua/oil/init.lua:1079: in function <.../oil.nvim/lua/oil/init.lua:1057>
        [C]: in function 'nvim_win_call'
        .../oil.nvim/lua/oil/init.lua:1057: in function 'callback'
        .../oil.nvim/lua/oil/adapters/files.lua:265: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>
stack traceback:
        .../oil.nvim/lua/oil/view.lua:680: in function 'render_buffer'
        .../oil.nvim/lua/oil/view.lua:905: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>
stack traceback:
        .../oil.nvim/lua/oil/config.lua:467: in function 'get_adapter_by_scheme'
        .../oil.nvim/lua/oil/util.lua:66: in function 'get_adapter'
        .../oil.nvim/lua/oil/view.lua:269: in function 'constrain_cursor'
        .../oil.nvim/lua/oil/view.lua:700: in function <.../oil.nvim/lua/oil/view.lua:681>
Could not find oil adapter for scheme '://'
stack traceback:
        .../oil.nvim/lua/oil/util.lua:68: in function 'get_adapter'
        .../oil.nvim/lua/oil/view.lua:269: in function 'constrain_cursor'
        .../oil.nvim/lua/oil/view.lua:700: in function <.../oil.nvim/lua/oil/view.lua:681>
[oil] could not find adapter for buffer '://'

It starts from setup(), with a callback on BufReadCmd.

I don't switch to insert mode, but the snacks.picker does on its buffer.

Also, here's a repro.lua that I can reproduce the bug from #573 (and when invoked via nvim -u repro.lua .).

-- 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,
  },
  { "folke/snacks.nvim", opts = { picker = {} } },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- It takes a few try to reproduce with `vim.schedule`
vim.schedule(Snacks.picker.files)
-- Can be reproduced with following reliably
-- Snacks.picker.files()

Got it, yeah it seems like the quick switch to the snacks picker and insert mode is likely the culprit here

I also reproduce this error when opening telescope quickly after oil loads. Just in case that helps at all.

The act of passing the bufnr and winnr across the schedule boundary makes total sense to me though, the ID of 0 should only ever be used in fully sync code.

If bufnr is not the current buffer, then 0 is the wrong winid to be using. Could we either pass the winid as well, or check to see if the current buffer == bufnr and early return?

I went with early return instead of passing winid, as constrain_cursor is synchronous.

I also reproduce this error when opening telescope quickly after oil loads. Just in case that helps at all.

I'm having the same issue (annoying because I have scripts that open directories and start telescope). Thanks to everyone who is working on fixing this.