You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reproduced and fixed. Thanks for the report — the reproduction steps were exactly right, and the "after leaving the app" detail is what pinned it down.
Your cards are safe. We verified the server-side copy of the affected collection against a pre-incident backup: same card count, same copies, same quantities. Nothing was lost in the cloud. The loss was on the device only.
What was happening
Finishing an import wrote the imported cards to local storage using a "replace everything" operation instead of a "merge" one. So importing N cards deleted every other card from the device's local database.
It stayed invisible for the rest of the session because the in-memory copy was updated correctly — the app kept showing the full collection. Only on the next app launch, when it re-read local storage, did the earlier import appear to vanish. Background sync couldn't repair it either: from the server's point of view nothing had changed, so it correctly reported no updates.
The same code path is used by the multi-select "add these cards" sheet, so that could truncate local storage too. Both are fixed by the same change.
Workaround until the next build
Log out and log back in. That clears local storage and pulls a fresh full copy from the server, which still has everything.
Please avoid importing again before that. If you import while the app is showing a truncated collection, the app tells the server that truncated view is authoritative — and that can cause real data loss for cards present in both. That did not happen to you, but it is the risk the workaround avoids.
Fix
Branch fix/import-truncates-local-collection (in the private code repo). The repository now has an explicit merge operation for partial writes, with the replace-everything one reserved for full cloud snapshots — so the two can't be confused again.
Covered by regression tests that run against real local storage, including a genuine app-restart simulation and a check that a re-import after a relaunch can never push a smaller set of copies than the device holds. Reverting the fix turns them red.
Leaving this open until it ships in a release build.
Activity
Matthieu1999 commentedon Aug 28, 2026
Reproduced and fixed. Thanks for the report — the reproduction steps were exactly right, and the "after leaving the app" detail is what pinned it down.
Your cards are safe. We verified the server-side copy of the affected collection against a pre-incident backup: same card count, same copies, same quantities. Nothing was lost in the cloud. The loss was on the device only.
What was happening
Finishing an import wrote the imported cards to local storage using a "replace everything" operation instead of a "merge" one. So importing N cards deleted every other card from the device's local database.
It stayed invisible for the rest of the session because the in-memory copy was updated correctly — the app kept showing the full collection. Only on the next app launch, when it re-read local storage, did the earlier import appear to vanish. Background sync couldn't repair it either: from the server's point of view nothing had changed, so it correctly reported no updates.
The same code path is used by the multi-select "add these cards" sheet, so that could truncate local storage too. Both are fixed by the same change.
Workaround until the next build
Log out and log back in. That clears local storage and pulls a fresh full copy from the server, which still has everything.
Please avoid importing again before that. If you import while the app is showing a truncated collection, the app tells the server that truncated view is authoritative — and that can cause real data loss for cards present in both. That did not happen to you, but it is the risk the workaround avoids.
Fix
Branch
fix/import-truncates-local-collection(in the private code repo). The repository now has an explicit merge operation for partial writes, with the replace-everything one reserved for full cloud snapshots — so the two can't be confused again.Covered by regression tests that run against real local storage, including a genuine app-restart simulation and a check that a re-import after a relaunch can never push a smaller set of copies than the device holds. Reverting the fix turns them red.
Leaving this open until it ships in a release build.