Encrypted events seem to get into handleCallEvent()

[SimonBrandner]

[Palid]

Related: matrix-org/matrix-js-sdk#1834
Looks like this PR has shown us additional problems we didn't know about before.

[SimonBrandner]

It's quite unclear to me how can this happen since we have this line: https://github.com/matrix-org/matrix-js-sdk/blob/977720cee47e49371db46dca291868b78b2c29ca/src/webrtc/callEventHandler.ts#L61

[dbkr]

Interesting. How do we know this is an encrypted event? Does this visibly cause any badness? How did you repro this?

[SimonBrandner]

Interesting. How do we know this is an encrypted event?

The log says, so - event.getType() === "m.room.encrypted"

Does this visibly cause any badness?

No, it just unnecessarily goes through handleCallEvent wasting some tiny amount of time

How did you repro this?

Open an E2EE and receive a message

[SimonBrandner]

I think I've run out of ideas here, if someone wants to take a look please go ahead

[dkasak]

I just stumbled across this while debugging something else. These are m.bad.encrypted messages that we're injecting when we can't decrypt a message:

content: Object {
    msgtype: "m.bad.encrypted",
    body: "** Unable to decrypt: The sender's device has not sent us the keys for this message. **"
}

I think the reason we're reporting m.room.encrypted instead of m.room.message (with msgtype: m.bad.encrypted) is that we're recording the type at the beginning of the handleCallEvent function and it gets decrypted between that location and the logger call.

It's quite unclear to me how can this happen since we have this line: https://github.com/matrix-org/matrix-js-sdk/blob/977720cee47e49371db46dca291868b78b2c29ca/src/webrtc/callEventHandler.ts#L61

That's not the only place from which can reach handleCallEvent, since it's also called directly here so maybe that has something to do with it?

No, it just unnecessarily goes through handleCallEvent wasting some tiny amount of time

I think log pollution is also quite counterproductive when it comes to debugging, especially when we're producing spurious warnings/errors.

To reproduce, just join an encrypted room with some existing history for which you won't receive keys (e.g. the Megolm test room) and watch the console.

[SimonBrandner]

I think the reason we're reporting m.room.encrypted instead of m.room.message (with msgtype: m.bad.encrypted) is that we're recording the type at the beginning of the handleCallEvent function and it gets decrypted between that location and the logger call.

It's quite unclear to me how can this happen since we have this line: https://github.com/matrix-org/matrix-js-sdk/blob/977720cee47e49371db46dca291868b78b2c29ca/src/webrtc/callEventHandler.ts#L61

[dkasak]

@SimonBrandner Did you perhaps miss this later part of my comment?

That's not the only place from which can reach handleCallEvent, since it's also called directly here so maybe that has something to do with it?

Maybe the link in that was not obvious; I was linking to this direct handleCallEvent which doesn't go through evaluateEventBuffer (which contains the line you're quoting): https://github.com/matrix-org/matrix-js-sdk/blob/c2a0c02898f6bd1d4e508559b67880494005e1de/src/webrtc/callEventHandler.ts#L113