Runtime validation of documents JSON via zod_gen

[kasbah]

If we used zod_gen in notebook-types we could generate code to do runtime validation of our JSON in JS. This would help us avoid problems like #902 and we could be more confident about what's in our Automerge docs in general.

Since the frontend edits these documents directly it makes me uneasy that what is sending is only checked at compile time and not at runtime.

What do you think? @jmoggr @epatters

[jmoggr]

Validation Method

We already have a method for detecting corrupted documents: the existing de-serialization used by the migrations. Anywhere we might want to use zod we could just use the rust deserializer.

Pros:

• The same checks would run on the client and server
• Does not require extra maintenance/effort
• Does not introduce another set of rust -> typescript types (we already have 2)

Cons:

• Zod would give better error messages
• Zod might be faster?

I think the only thing that Zod really gives us is better error message, and the serde error messages are enough to flag the problem. If issues like this become systemic/frequent then we might benefit from better errors, but I'm skeptical that it's worth doing preemptively.

---

Validation Methodology

When would we run this?

• Running it on every change (keystroke) would slow the editor down, possibly by a noticeable amount. We could test this, but I think we should be staying off the hot path of the editor as much as possible.
• We already run validation via the migration step whenever we load the document on the client or on the server.
• We could run it periodically on the client

---

A thought:
It's not obvious that the corruption happened on the client, or would have been visible at all to the client. Through bugs It is possible for the automerge server and client to have different views of the prosemirror document. The automerge-prosemirror package uses different code for loading the initial document and for applying changes after loading, and it is not bug free.

I don't think this changes anything, but it highlights that even validating every change on the client might not have prevented #902

[epatters]

I previously suggested that we do runtime validation of JSON documents in the frontend or backend, perhaps even both. See:

• Validate JSON data for documents in frontend #421
• Validate JSON data for document refs in backend #304

I think this issue is a dupe of #421, with the caveat that I suggested using JSON Schema rather than Zod (#803). I have a preference for JSON Schema since it's a standard with support in other ecosystems, including in Julia, but I'm open to being persuaded otherwise. Note that I've never actually used Zod, though I know it's popular.

Re: @jmoggr's point about migrations, IIRC I created the two issues cited above before we were migrating any JSON data. I agree that this considerably complicates the question. Not only does it suggest that validation could be redundant, we'd have to be sure to validate documents against the right version of the notebook types. In particular, we'd have to generate validators for all possible schema versions. So I agree with Jason that, in light of our current design, we should think carefully before proceeding.