Closed hughns closed 1 week ago
Looking at possible causes:
if (existingKeyAtIndex && existingKeyAtIndex.timestamp > timestamp) {
but there is no Ignoring new key at index
log entryif (existingKeyAtIndex && keysEqual(existingKeyAtIndex.key, keyBin)) {
would silently fail, but there is no previous Setting key at index
entry for the same keyif (delayBeforeUse) {
but delayBeforeUse
is only true when creating your own key not consuming one from elsewherethis.emit(MatrixRTCSessionEvent.EncryptionKeyChanged, keyBin, encryptionKeyIndex, participantId);
failed - TODO: what is the code path from here via the widget API in to the embedded EC?So, the log lines are confusing as we have two JavaScript contexts: EW and embedded EC within the iframe.
The log lines above are entirely expected within the EW context. And there is actually no-one listening in to this.emit(MatrixRTCSessionEvent.EncryptionKeyChanged, keyBin, encryptionKeyIndex, participantId);
within EW.
What is supposed to happen is the that (decrypted) events get sent via the StopGapWidget
in EW which in turn forward to the EC context. In that context the events are processed by the MatrixRTC code again and passed on to EC as expected.
n.b. There is an optimisation by making it so that the EW context does not track the encryption keys as it doesn't need to.
The underlying issue is that we keep hitting the condition here because we see sequences of emits like this:
event1
with isDecryptionFailure()=trueevent2
with isDecryptionFailure()=falseevent1
with isDecryptionFailure()=falseWhen event1
is emitted for the second time it is ignore as it appears in the timeline before event2
which has already been "seen".
n.b. There is an optimisation by making it so that the EW context does not track the encryption keys as it doesn't need to.
This is being tracked by https://github.com/element-hq/element-call/issues/2566.
I've done a possible fix for this in https://github.com/matrix-org/matrix-react-sdk/pull/12890 but I don't know if this is the right place/direction to fix it as it would change the semantics for other users of the widget API.
The conclusion is that we won't fix this until we use to-device messaging for key distribution.
Then there is no subsequent log entry like: