Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

noisy `-32801` ("Content Modified") errors

Aberta
  • Algo errado?
#3,420 4 comentários 6 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Pouca atividade
Stack de tecnologia
lua, neovim
Domínio
devtools

Direção de pesquisa

Comece rastreando o caminho da solicitação textDocument/semanticTokens/full e como as notificações textDocument/didChange afetam as solicitações em andamento. Compare esse comportamento com a especificação de LSP responseError.code; o trabalho estará concluído quando alterações normais de documentos enfileiradas não produzirem mais -32801, enquanto modificações genuinamente externas ainda puderem produzi-lo.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

bug
How are you using the lua-language-server?

NeoVim

Which OS are you using?

MacOS

What is the issue affecting?

Other

Expected Behaviour

In the request-completion path, when the server has computed a result against document version V, return that result regardless of whether didChange for V+1 (or later) has since arrived. Only return -32801 if the document
modification was genuinely external / out-of-band — which is rare in normal usage and not what didChange represents.

If pre-empting in-flight requests on didChange is desired as an optimization, the spec-compliant signal is for the client to send $/cancelRequest. The server should not unilaterally short-circuit valid in-flight work with -32801.

Per the spec, the client is supposed to handle staleness via cancellation. With lua-language-server pre-empting that decision and erroring instead:

  • Clients that handle -32801 strictly as an error end up logging spurious errors (cf. neovim/neovim#40208).
  • Clients that could have used the older-version result (perfectly valid per the spec — "even computed on an older state might still be useful") never get the chance.
  • Clients that wanted to cancel can no longer rely on $/cancelRequest semantics because the server has already aborted on its own initiative.
Actual Behaviour

Sending a fast sequence of didChanges while semantic-tokens requests are in flight causes the server to error every in-flight request with:

{ "code": -32801, "message": "Content modified." }

even though the modification was delivered through normal didChange notifications, not "outside normal conditions."

Reproduction steps
  1. Open a Lua file in any LSP-capable editor that requests semanticTokens/full (e.g. Neovim 0.12+).
  2. Start typing across multiple lines, fast enough that successive didChange notifications outpace the server's processing.
  3. Observe: every in-flight semantic-tokens request comes back with -32801 Content modified. instead of a (possibly stale) result.
Additional Notes

lua-language-server returns LSP error -32801 ("Content Modified") in response to textDocument/semanticTokens/full (and likely other requests) whenever a textDocument/didChange notification arrives before the response is sent.
This contradicts the LSP specification, which explicitly forbids using -32801 for content changes detected in unprocessed messages — i.e. for the exact case currently being signaled.

What the spec says:

LSP §responseError.code (specifically the ContentModified = -32801 entry):

The server detected that the content of a document got modified outside normal conditions. A server should NOT send this error code if it detects a content change in its unprocessed messages. The result even computed on an older
state might still be useful for the client.

If a client decides that a result is not of any use anymore the client should cancel the request.

So the intended semantics are:

  • -32801 is for "out-of-band" content modification (e.g., the file on disk changed in a way the server can't reconcile with its in-flight state).
Log File

No response

Linguagem predominante
Lua
Estrelas
4.4k
Forks
442
Merge médio
8d 9h
PRs com merge (30d)
1

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de LuaLS/lua-language-server

Todas as issues de LuaLS/lua-language-server

Issues semelhantes

Mais issues de Lua

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.