Client/Cloud compatibility

[kazcw]

Background: Parser/YDoc Compatibility

Parser version: The parser has a version. Currently, it is implicit (we aren't assigning a number to it, or tracking breaking changes at all). Changes to the parser (mainly app/ydoc-shared/ast and lib/rust/parser) that alter the relationship between source code and YDoc content result in a new parser version.

Version mismatch: All users of a YDoc must have the same parser version. If this is not the case, problems will occur ranging from small bugs to failure to load the graph (#11493).

Ignoring compatibility breaks the Cloud

Currently, Nightly builds using a parser older or newer than the version deployed in the Cloud:

• Exhibit version mismatch bugs
• Are unable to detect and report the incompatibility

Quick Solution: Compatibility warnings

Assign a version number to the parser. If the client's version is less than the ydoc-server's, recommend updating. With the right tests, we should be able to reliably enforce that compatibility-breaking changes are accompanied by version number updates.

Pros:

• Simple to implement.

Cons:

• Users sometimes forced to update.
• Developers have to try to minimize compatibility-breaking parser updates.
• Important to keep Cloud version compatible with current version in Nightlies; we can't have the user needing an older nightly.

Better solutions

A better long-term solution will take some time to design, but here are some ideas:

Live updates

Client runs GUI assets obtained from Cloud.

Single-user mode

The client runs the ydoc-server.

Pros:

• Developers can release updates without any ydoc-server compatibility concerns.

Cons:

• For collaborative editing, we'd need to also support running the ydoc-server independently.

Rejected: Forward-compatible YDoc

Flexible YDoc versioning is possible, but not a good solution for us. The YDoc data model constraints for forward compatibility are very different from the constraints for intent-preservation; it is not possible to make the YDoc structures parser-version independent without losing properties like "concurrent user edits never cause invalid syntax".

[kazcw]

Regardless of what better long-term solution we might come up with, I think we should implement compatibility warnings right away:

Compatibility warnings:

• Display a warning if the GUI's parser is incompatible with the ydoc-server's (based on parser version numbering)
• Add tests checking that the parser's behavior matches expectations for the current version

[farmaazon]

Technically, it's not only a matter of parser/ydoc-server, but also language server API, however it's now much easier to keep forward-compatibility in the latter. There's also cloud backend...

I would add one point to Better Solutions: cloud could spawn ydoc-server (and maybe even language-server) which version matches the version of the client requesting project opening. There may be problems, though, if the same project is opened by two different client's versions. Not sure also about scheduled runs. @PabloBuchu do you think it's possible/desirable? And do you as Cloud team maybe already considered versions mismatch between cloud and client in general? I