Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

textDocument/didChange version number reaches maximum value #2053

Open
krzyzanowskim opened this issue Oct 30, 2024 · 5 comments
Open

textDocument/didChange version number reaches maximum value #2053

krzyzanowskim opened this issue Oct 30, 2024 · 5 comments

Comments

@krzyzanowskim
Copy link
Contributor

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#versionedTextDocumentIdentifier

  • The version number of a document will increase after each change,
  • including undo/redo. The number doesn't need to be consecutive.

What happens when the version number reaches the number.max value, and there are still changes?
At that point, server won't see new changes as version can't increase anymore. (It may sound like an edge case, but shouldn't specification address edge cases?).

After reaching the max value, I propose resetting the version counter to 0.

@jwortmann
Copy link

jwortmann commented Oct 30, 2024

It may sound like an edge case

LSP uses JSONRPC and there doesn't seem to be any limitation on the integer size in the JSONRPC or JSON specs: https://stackoverflow.com/questions/13502398/json-integers-limit-on-size

So in practice it could still be limited on the implementation language of clients and servers. For example Python has also no limits on integer size, but if we take JavaScript, then it looks like the limit is Number.MAX_SAFE_INTEGER which is $2^{53} - 1 = 9007199254740991$. While the version number doesn't need to be consecutive, I guess it's a sane assumption that the version starts with 1 and then is just incremented by 1 by a small number after each document change. So let's assume that there is one change per second (usually the client does some kind of debouncing while typing, so this would mean half a second of typing, then half a second pause and so on), and let's assume that you type 24 hours per day without sleep. Then it would take $9007199254740991/3600/24/365 = 2.856 * 10^8$ years or 285 million years before an overflow occurs.

Edit: Actually I see now that the integer type is limited to $2^{31}-1$ in the LSP specs (https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#integer). Then it would still be around 68 years before that maximum is reached, with continuously 1 change per second. Not sure if that case is really worth an extra consideration in the specs.

@krzyzanowskim
Copy link
Contributor Author

I guess it's a sane assumption that the version starts with 1 and then is just incremented by 1 after each document change.

That is not a specified requirement. It may start at 1 billion and increase by billion or any number.
But that is exactly my point: given that version numbering is arbitrary, it may reach the limit in one step. And what then?

@jwortmann
Copy link

It may start at 1 billion and increase by billion or any number.

What would be the actual use case why a client would do this?

My reasoning as a client maintainer/contributer is, that requiring the version number to reset to 0 when the maximum is reached would be kind of a breaking change which every client and every server would need to implement in order to be fully spec compliant. I don't want to implement that if there is no practical relevance for it. So I would propose to just leave this as "undefined behavior", or if this theoretical case should really be considered in the specs, then rather add a sentence like "Please restart your editor every 100 years to ensure that the document synchronisation works correctly" or so...

@dbaeumer
Copy link
Member

I agree with @jwortmann comments. What we can do is to add a sentence to the spec to start when possible with a low number and that there are no means to wrap since the assumption is that editors don't run for so long.

@DanTup
Copy link
Contributor

DanTup commented Nov 4, 2024

Out of interest, are version numbers reusable after closing/re-opening a doc? (it doesn't seem obvious from the spec, but maybe that should be noted too).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants