[martgil]

This PR fixes storage key collision for identical user accounts.

close #6251

---

Tests (delete all except exactly one):

• Tests added or updated

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities
• if this PR fixes a security issue: I tried to bypass the new fix, and failed (leave unticked if this PR is not a security fix)
• is documented clearly and usefully, or doesn't need documentation

[martgil]

Unrelated tests are failings so often, sorry.

[martgil]

This one is ready for a review. Thank you!

[martgil]

Hi @sosnovsky - This one is ready for a review. Thanks!

[sosnovsky]

Hi @martgil, I implemented some changes to improve migration reliability - failures stop the migration without losing existing data, while interrupted migrations are resumed on the next attempts. Also users can now continue using accounts without storage-key collisions, while previously a collision between accounts blocked the entire extension until the affected accounts were reconfigured. Can you please check my changes, to see if I missed something, thanks!

[martgil]

Hi @martgil, I implemented some changes to improve migration reliability - failures stop the migration without losing existing data, while interrupted migrations are resumed on the next attempts. Also users can now continue using accounts without storage-key collisions, while previously a collision between accounts blocked the entire extension until the affected accounts were reconfigured. Can you please check my changes, to see if I missed something, thanks!

Thanks @sosnovsky, reviewed your changes together with the rest of the branch, and they look good.

I pushed one follow-up commit: emailKeyIndex is now fully collision-free. The escape was variable-length hex, so a!1@b.com and aȑ@b.com (both pass Str.isEmailValid) produced the same key cryptup_a~211~40b~2ecom_keys. Escapes are now fixed-width, so the encoding is prefix-free. I updated the hardcoded key literals in the tests, added a regression assertion, and made the large-snapshot test compare sorted keys instead of relying on storage key order.

[martgil]

Hello @sosnovsky - Please kindly re-check for the last changes I've made and see if it looks good. Thanks!