Backend starting before the frontend is ready, resulting in missed events
Adding duplicate CSRs
I found an existing bug where we could actually remove peers (originating from the invite link) from the peer list if certificates replicated before CSRs, because we used CSRs to update the peer list. @ikoenigsknecht, this could be related to the issue where you said the dialer stopped working, perhaps it didn't have any peers to dial. In the PR, we use the same definition for all users as the frontend (CSRs + certs) when finding peers and we always retain peers from the invite link even if we don't have their cert or CSR yet.
The peer issue was really easy to reproduce when CSRs didn't replicate, which I was also lucky enough to reproduce. Apparently due to our duplicate CSR issue (I had around 3670 CSRs), that caused CSRs to take 30 minutes or so to replicate. So that's interesting. It looks like we had this saga checkLocalCsr which would re-add a CSR in certain cases or not add the user's CSR at all. In the case where the CSR doesn't get added at all, we could get the disappearing message effect that @kingalg saw because we don't display messages unless we know about the user (CSR or cert must exist). In this PR, we add the CSR once (right after community is launched).
Also the backend was starting before the frontend was ready on mobile only. Thanks @EmiM for spotting that. This resulted in missing a CHANNEL_SUBSCRIBED event and thus not being able to send a message (having it greyed out indefinitely). It looks like mobile connects with native code to the backend in order to get push notifications which causes the backend to start, then the actual frontend code connects and by then it's missed the CHANNEL_SUBSCRIBED event. So I added a new START event for the frontend to explicitly tell the backend it's ready.
Pull Request Checklist
[ ] I have linked this PR to a related GitHub issue.
[ ] I have added a description of the change (and Github issue number, if any) to the root CHANGELOG.md.
(Optional) Mobile checklist
Please ensure you completed the following checks if you did any changes to the mobile package:
[ ] I have run e2e tests for mobile
[ ] I have updated base screenshots for visual regression tests
Fixes for the following issues:
I found an existing bug where we could actually remove peers (originating from the invite link) from the peer list if certificates replicated before CSRs, because we used CSRs to update the peer list. @ikoenigsknecht, this could be related to the issue where you said the dialer stopped working, perhaps it didn't have any peers to dial. In the PR, we use the same definition for all users as the frontend (CSRs + certs) when finding peers and we always retain peers from the invite link even if we don't have their cert or CSR yet.
The peer issue was really easy to reproduce when CSRs didn't replicate, which I was also lucky enough to reproduce. Apparently due to our duplicate CSR issue (I had around 3670 CSRs), that caused CSRs to take 30 minutes or so to replicate. So that's interesting. It looks like we had this saga checkLocalCsr which would re-add a CSR in certain cases or not add the user's CSR at all. In the case where the CSR doesn't get added at all, we could get the disappearing message effect that @kingalg saw because we don't display messages unless we know about the user (CSR or cert must exist). In this PR, we add the CSR once (right after community is launched).
Also the backend was starting before the frontend was ready on mobile only. Thanks @EmiM for spotting that. This resulted in missing a CHANNEL_SUBSCRIBED event and thus not being able to send a message (having it greyed out indefinitely). It looks like mobile connects with native code to the backend in order to get push notifications which causes the backend to start, then the actual frontend code connects and by then it's missed the CHANNEL_SUBSCRIBED event. So I added a new START event for the frontend to explicitly tell the backend it's ready.
Pull Request Checklist
(Optional) Mobile checklist
Please ensure you completed the following checks if you did any changes to the mobile package: