Restoring account gives different profile (Safe) address

[mikozet]

Describe the bug When account is in onboarding state and we try to restore it from different device. Sometimes it appears that we get a different profile (Safe) address after restoring an account

To Reproduce Steps to reproduce the behavior:

1. Create a new account and leave it it onboarding state
2. Logout from that account
3. Open new browser window (can be different browser for example Safari but noticed that also on Chrome)
4. Restore your previous account from seed phrase.
5. You should be logged in with different profile address

Expected behavior Your profile address should not changed

Screenshots If applicable, add screenshots to help explain your problem.

Desktop-Computer (please complete the following information):

• OS: macOs Catalina 10.15.7
• Browser: Safari version 15.2 (15612.3.6.1.8, 15612), Chrome version 97.0.4692.71 (Oficjalna wersja) (x86_64)

Additional context - original profile address @kowalski: 0x713cF02c82e46618940211e18Bd0784f5429Cfd6 - restored address: 0x2898ab53be65301a6094a108A686297DF9ffA66D - non of the safes are in the Graph (this is expected) {safe (id: "0x713cF02c82e46618940211e18Bd0784f5429Cfd6"){ deployed organization owners{ id } }} - in relayer db: select * from relay_safecreation2 where safe_id='0x713cF02c82e46618940211e18Bd0784f5429Cfd6' ORDER BY created ASC; - owner of both accounts:0x5e2eA7b0b967086A9AC4B1Ede79C2746e5326849 - but the nonce is different - it is used by the relayer to recover the account: https://github.com/CirclesUBI/safe-relay-service/blob/e6844e2b92316ddc099d5b39711487a6e46d5a93/safe_relay_service/relay/views_v3.py#L63 - 46207115617131 (seen in the relayer db for the original address, also what we expect from generateDeterministicNonce() in myxogastria) - 43185446479945 (seen in the relayer db for the second addess)

[llunaCreixent]

This is also observed in accounts that are already validated.

[llunaCreixent]

Did this issue happen every time? or only some times?

[adzialocha]

To track this down we could:

1. Add tests reproducing the flow from restoring via seed phrase and assert that the nonce did not change, hopefully we will be able to reproduce the problem there and see exactly what actions take place in redux
2. Check our process of restoring, maybe there is a bug sitting somewhere reading / writing from LocalStorage and redux not being aware of these changes yet? Or the order of redux actions is causing a race condition. Or both!
3. Use a framework for using local storage with redux to account for maybe unknown caveats combining both: https://www.npmjs.com/package/redux-localstorage (not a recommendation, just an example)

[triaslucia]

Check if this is still an issue