Random can't save errors on save: compiler callback error followed by "can't create backup"

[Nora-n]

Description

I've been editing and compiling LaTeX files using LazyVim and Vimtex for over a year. Since a few days, I have errors randomly popping up whenever I want to save "too quickly", when I have a split window showing at least 2 buffers, with an error message return require'lazyvim.util.ui'.statuscolumn(...)_check_callback[4]..vimtex#compiler#callback[54]..vimtex#qf#open[4]..vimtex#qf#setqflist[31]..vimtex#qf#bibtex#addqflist[4]..234, line 2, or return nvim_bufferline(...).ui'.statuscolumn(...)_check_callback[4]..vimtex#compiler#callback[54]..vimtex#qf#open[4]..vimtex#qf#setqflist[31]..vimtex#qf#bibtex#addqflist[4]..238, line 2, or even sometimes return require'lazyvim.util.ui'.statuscolumn(...)13]..vimtex#parser#toc#parse, line 78.

By "too quickly", I mean that if I wait long enough (5 to 10 seconds), I can save alright.

This error is actually hiding a prompt, asking me a y/n question that I can't read unless I type on another key. Typing n doesn't save. Typing y tries to save, but gives the error message E509: Cannot create backup file (add ! to override). This also creates a copy of said file in my root git directory. Writing with ! does write, but the compilation doesn't work on that file anymore?

I checked the backupdir with :se backup? backupdir?, which was setup to backupdir=~/.local/state/nvim/backup//, and added the following lines in my init.lua:

-- set undo and backup
local prefix = vim.fn.expand("~/.local/state/nvim")
vim.opt.undodir = { prefix .. "/undo/" }
vim.opt.backupdir = { prefix .. "/backup/" }
vim.opt.directory = { prefix .. "/swap/" }

All of my previous backups, undo and swap were indeed already in these folders, and this change did nothing.

If I have no other buffer opened, this doesn't seem to arise.

This isn't a clear issue because I can't get where it lies: is it vimtex, is it lazyvim… sorry for the mess.

minimal.tex

\documentclass{article}

\begin{document}
  Hello world
\end{document}

Steps to reproduce

1. nvim file.tex
2. Edit, compile
3. Save
4. Edit and save
5. Error

Expected behavior

I expect file saving to work without error, and my neovim not to create a file at my root git directory.

Actual behavior

I need to wait between saves for it to work, and a previous copy (backup) of the file I'm editing is created on my root directory

Do you use a latexmkrc file?

No

VimtexInfo

System info:
  OS: Arch Linux
  Vim version: NVIM v0.9.2
  Has clientserver: true
  Servername: /run/user/1000/nvim.1379307.0

VimTeX project: minimal
  base: minimal.tex
  root: /home/nora/Documents/Enseignement/Prepa/test
  tex: /home/nora/Documents/Enseignement/Prepa/test/minimal.tex
  main parser: current file verified
  document class: article
  packages: expl3 xparse
  compiler: latexmk
    engine: -pdf
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
    job: 
      jobid: 120
      output: /tmp/nvim.nora/IXTAwy/0
      cmd: max_print_line=2000 latexmk -verbose -file-line-error -synctex=1 -interaction=nonstopmode -pdf -pvc -view=none -e '$compiling_cmd = ($compiling_cmd ? $compiling_cmd . " ; " : "") . "echo vimtex_compiler_callback_compiling"' -e '$success_cmd = ($success_cmd ? $success_cmd . " ; " : "") . "echo vimtex_compiler_callback_success"' -e '$failure_cmd = ($failure_cmd ? $failure_cmd . " ; " : "") . "echo vimtex_compiler_callback_failure"' 'minimal.tex'
      pid: 1426863
  viewer: Zathura
    xwin id: 121634819
    cmd_start: zathura  -x "/usr/bin/nvim --headless -c \"VimtexInverseSearch %{line} '%{input}'\"" --synctex-forward 13:1:'/home/nora/Documents/Enseignement/Prepa/test/minimal.tex' 'test/minimal.pdf'&
  qf method: LaTeX logfile

[Nora-n]

Found to be related to Noice and maybe custom statuscolumn. For reference, see this comment on LazyVim.

[lervag]

I spent some time on this without giving a reply (sorry), but I'm glad to hear you figured it out (or partly so). I did not really have any good idea what could be causing the issue and I was planning on a recommendation to check if it could be related to lazy.nvim.