Zod rejects UUIDs that Postgres deems valid

[alco]

Originally reported by @fooware in Discord

Turns out that Postgres will accept a truly random UUID, but Zod will reject it if it doesn't have the version nibble and possibly also the variant bits set correctly.

The end result is that if such an "invalid" UUID is entered into the database from a system that doesn't validate the input with Zod, Electric sync will permanently die on all clients until the offending row is removed.

You don't get any good errors or anything either indicating the underlying problem:

I mean, it is technically correct, but having stricter UUID checks in Electric vs Postgres is a bomb waiting to happen at the worst possible time in production, IMHO.

Related issue / discussion at Zod:
colinhacks/zod#2122

---

To get an example to test, simply generate a valid V4 UUID, like this one:

76e1760a-d17a-41cd-9453-d8a9d6c994e0 

Then replace the -4 (version 4) with for example -f (not a valid version) like so:

76e1760a-d17a-f1cd-9453-d8a9d6c994e0 

Postgres will accept this "UUID" just fine as for example a primary key, but Zod and Electric will throw an error trying to read it from the DB.

[linear]

VAX-1881 Zod rejects UUIDs that Postgres deems valid

[KyleAMathews]

👋 we've been working the last month on a rebuild of the Electric server over at a temporary repo https://github.com/electric-sql/electric-next/

You can read more about why we made the decision at https://next.electric-sql.com/about

We're really excited about all the new possibilities the new server brings and we hope you'll check it out soon and give us your feedback.

We're now moving the temporary repo back here. As part of that migration we're closing all the old issues and PRs. We really appreciate you taking the time to investigate and report this issue!