textDocument/didChange version number reaches maximum value

[krzyzanowskim]

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]

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]

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]

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]

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.