Add credit card bulk-import APIs for store migration - #7585
Merged
Conversation
with_savepoint, timestamp_from_millis and CounterUpdate were added to addresses.rs for the address with-meta import. Credit cards need all three for the same reason, and none of them is address-specific, so share them rather than duplicating. No behaviour change: with_savepoint goes from module-private to pub(crate) and CounterUpdate's re-export moves from crate::db::addresses to crate::db, which is the only caller change.
Mirrors the address with-meta API for credit cards, so an application migrating a credit card collection into this store can keep each record's guid, timestamps and change counter: add_credit_card_with_meta add_many_credit_cards_with_meta update_credit_card_with_meta add_many_credit_card_tombstones delete_all_credit_cards Mostly wrappers over add_internal_credit_card, which already took the metadata. The exception is update_internal_credit_card, which took `flag_as_changed: bool` and could only increment the change counter. It now takes CounterUpdate, as the address side does, because an imported record's counter is owned by the caller and has to be set rather than bumped. The sync caller is unchanged in behaviour. cc_number_enc is stored exactly as supplied and is not checked against the store's key, matching add_credit_card: Desktop's interim migration carries ciphertext produced by the OS key store, which this component cannot decrypt by design. Note the cost of that. An imported record is absent from the mirror, so it is always selected for upload, and one undecryptable row fails the whole outgoing batch - so credit card sync stops until scrub_undecryptable_credit_card_data_for_remote_replacement blanks it.
jo
reviewed
Sep 7, 2026
jo
left a comment
jo
left a comment
Contributor
There was a problem hiding this comment.
That's slick!
At this point let's introduce timestamp validation, similar to
DimiDL
force-pushed
the
autofill-credit-card-with-meta
branch
from
September 7, 2026 11:00
1dce8cd to
8cb95d1
Compare
Logins got this in bug 2066257: a timestamp outside the range a JS Date can represent is reported as 0, "we don't know when". Autofill now does the same, at all three places a timestamp enters: - metadata an application supplies to the bulk-import APIs - every read out of the local database (addresses, credit cards, passports) - incoming sync payloads (addresses, credit cards) timestamp_from_millis only clamped negatives, which missed the values actually seen in telemetry: the negative-to-u64 reinterpretation happens in JS before the value reaches us, so they arrive already huge and .max(0) passed them through. MAX_DATE_MS and sanitize_timestamp move to the types crate, next to Timestamp, so logins and autofill cannot drift on what a representable date is. Logins reaches them via a re-export and is unchanged in behaviour.
DimiDL
force-pushed
the
autofill-credit-card-with-meta
branch
from
September 7, 2026 11:15
8cb95d1 to
e2abbe8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request checklist
[ci full]to the PR title.