Duplicated CSR's

[kingalg]

Version: 2.1.2-alpha.x (there were several alphas to test pipelines that day)
System: all

Issue: too many CSRs (that are duplicates) are generated after fulfilling specific conditions. Below, you can see a peer count of 387 when, in reality, there were under 10 (and it's correctly listed on the frontend).

Steps to recreate:

• Have a community with minimum 3 users (let's call them one, two and three)
• With another Quiet try to join as user "one"
• You will get a popup indicating that this username is already taken - try choosing username "two", app will let you do this (it should also be fixed)
• Type something as user two, restart the app, you will get popup "username already taken" again - choose username "one"
• Repete it several times, adding the username "three" as well, and after 5-6 rounds, you will see that the username is not changing anymore when you are typing something in a conversation and that CSR's count is way too high in logs.

[islathehut]

This appears to have just been an issue with replication. I added a ton of logging and tried tracing the actions of the CSR store and found that the CSR was being stored correctly on the identity and in the orbitdb store but once it synced with another peer it got into a confused state. This created a weird infinite loop because it kept creating a new CSR, stored it locally, and then got and update from the peer that conflicted with the local state and thought the CSR wasn't stored thus trying again.

The solution was simply to run store.load() on init to get the current state into memory before potentially replicating.

[holmesworcester]

What was the nature of the confused state, and where was that happening?

Also, is this the same problem you saw with duplicate peerid's?

[holmesworcester]

@ikoenigsknecht is this ready to be merged? if so let's merge it!

[kingalg]

Version: 2.2.0-alpha.2
mobile@2.2.0-alpha.2 | iOS 371
System: all

Fixed.