-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Various fixes related to peers, CSRs and backend startup #2455
Conversation
23b56a5
to
20fa367
Compare
|
||
this.logger(`Retrieving all users. CSRs count: ${csrs.length} Certificates count: ${certs.length}`) | ||
|
||
for (const cert of certs) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing that retrieving both certs and csrs is for the case when one of those DBs are not fully synced? In any other case you can't have certificate without csr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mirrors how we do things on the frontend and is helpful in the case where certs replicate before csrs.
de56de8
to
5bebb6e
Compare
fb663d7
to
2bb50c4
Compare
@@ -63,4 +66,6 @@ export function* launchCommunitySaga( | |||
} | |||
|
|||
yield* apply(socket, socket.emitWithAck, applyEmitParams(SocketActionTypes.LAUNCH_COMMUNITY, payload)) | |||
|
|||
yield* put(identityActions.saveUserCsr()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add the user's CSR once after launching community.
} else { | ||
yield* put(identityActions.saveUserCsr()) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just inlining registerCertificate
here to simplify things
const keyObject = yield* call(loadPrivateKey, identity.userCsr.userKey, config.signAlg) | ||
const signatureArrayBuffer = yield* call(sign, action.payload.message, keyObject) | ||
const signature = yield* call(arrayBufferToString, signatureArrayBuffer) | ||
const createdAt = yield* call(getCurrentTime) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-organizing a bit and adding additional logs.
if (!peers) { | ||
throw new Error('No peers provided and no peers found on current stored community') | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved this logic into updatePeersList
2bb50c4
to
147e2c8
Compare
Fixes for the following issues: - Peers can be deleted if CSRs don't sync - Backend starting before the frontend is ready, resulting in missed events - Adding duplicate CSRs
147e2c8
to
73a6b09
Compare
Fixes for the following issues: - Peers can be deleted if CSRs don't sync - Backend starting before the frontend is ready, resulting in missed events - Adding duplicate CSRs
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: