Skip to main content

max / goingson

Let a backup holding a sync account read back SyncAccount.user_id was skip_serializing with no default, so the field was absent from the JSON and had nothing to deserialize into. Any backup containing at least one sync account failed on read, which meant restore failed exactly for the users who had configured sync. Pre-existing and independent of the write path: the same file written by the old write_backup was equally unreadable. Found by a round-trip test seeding every collection. Matches the house pattern already on SavedView.user_id, where restore re-homes the row to the target user so the deserialized placeholder is never persisted.
Co-Authored-By
Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: Max Johnson <me@maxj.phd> · 2026-07-29 02:02 UTC
Signed with PGP, not checked
Commit: 8b166cb69c597206132b849bbe1fc7e978e2f208
Parent: 306597a
1 file changed, +5 insertions, -1 deletion
@@ -9,7 +9,11 @@
9 9 #[serde(rename_all = "camelCase")]
10 10 pub struct SyncAccount {
11 11 pub id: SyncAccountId,
12 - #[serde(skip_serializing)]
12 + /// User who owns this account. Not serialized into API responses; `default`
13 + /// lets a backup (which omits it) still deserialize, restore re-homes the
14 + /// row to the target user, so the placeholder is never persisted. Without
15 + /// the `default` any backup holding a sync account failed to read back.
16 + #[serde(default, skip_serializing)]
13 17 pub user_id: UserId,
14 18 pub provider: String,
15 19 pub account_name: String,