[joker-777]

Validates a pulled changeset in full before any record is prepared, so a bad pull fails with nothing touched.

Before, an invalid record halfway through a pull left the records before it prepared but never batched. They stayed in the record cache in that state, and update() on them threw until the app restarted.

Changes

• Checks before applying: every table change has created, updated and deleted arrays; every record has a string id and no _status, _changed or __proto__; deleted ids are strings
• An id that appears more than once in one table's created, updated and deleted is rejected (for example, updated and deleted in the same pull)
• Unknown tables are still skipped with a warning, for forward compatibility, so their contents aren't validated
• Behaviour change: a record with a non-string id is now rejected. Before, it was silently given a random id

Tests

New tests in applyRemote.test.js cover a bad second table, duplicate ids, malformed tables and malformed ids. Each checks that a record from earlier in the pull is unchanged and can still be updated. On master they fail with record.prepareUpdate was called on mock_projects#pSynced but wasn't sent to batch().

Verification

• On this branch: Jest passes on the host, 79 suites (the sqlite-node suite was left out because better-sqlite3 does not build on the host's Node; this change does not touch the adapters). flow check is clean, and ESLint is clean on the changed files
• The four sync PRs from us ([Sync] Apply batched pulls sequentially and notify observers once per pull #1984, [Sync] Validate the whole pulled changeset before applying any of it #1985, [Sync] Track changed columns on locally created records #1986, [Sync] Make sync bookkeeping linear-time #1987) touch applyRemote.js and its tests in separate places. They merge into master together without conflicts, and Jest passes on the result

🤖 Generated with Claude Code

[StasDoskalenko]

Hi @joker-777, thank you, that's a great catch on the half-prepared records!

I maintain NitromelonDB, a maintained fork of WatermelonDB (New Architecture, Nitro Modules). This applies there too: validateRemoteRaw still runs per record while preparing, so an invalid record halfway through a pull leaves the earlier ones prepared.

Our fork was rewritten in TypeScript (strict mode) to reduce the chance of bugs like this one slipping through, so I think the community would really benefit if you opened your PRs against it too. The code lives in src/sync/impl/applyRemote.ts there.

If you don't have the time or would rather not, no worries at all, I'm happy to port it myself. Just let me know. Thanks a lot!