Waiting for this message, this may take a while.

532910 commented 4 years ago

Phone was updated from the latest stable riot-android to element via GPlay (no beta subscription)

Now all messages in all e2ee direct chats including new messages are: Waiting for this message, this may take a while.

After update the phone was verified via pitcture sequence with riot-web. All contacts are verified and has green point/shield on all devices, all contacts are on my own synapse instance (1.15.1-1 debian stable).

Cross-signing is enables, Keys are trusted, Private keys are not known:

I tried to clear cache and to restart phone without sucess.

lindhe commented 2 years ago

Only after I get around to it and if I am successful. :D

smeyersdev commented 2 years ago

Happened again. See my post above. Situation was similar to before:

Received encrypted messages from my wife, but she could read my messages
Wife's phone is on mobile LTE internet while mine is on the home Wifi
Her phone is a Pixel 3 with latest update state and Element installed from Play Store
My phone is OnePlus 5T running ungoogled LineageOS. Element installed from F-Droid. Element version is 1.3.7 [40103070] (F-8b98c8fe).
We both are registered to matrix.org

2 days before, I used Element Web on PC and deleted all sessions (older web sessions and all Android sessions). Then I logged into Element again on my phone and tablet.

Solved it the following way:

Go to Androids app settings for Element
Force end element
Clear cache of Element
Start element again

Then after few seconds, the messages were decrypted.

chr-1x commented 2 years ago

Happened to my partner this morning. Messages sent from my iphone would not decrypt on their end but messages from my desktop client did.

I'm on Element iOS, 1.6.8 (20211117180457) and Element Web (electron desktop client) 1.9.5
They are on Element Android installed from the play store (most recent as of today's date, presumably)
We were both on wi-fi the whole time, on all devices involved
Restarting either of our apps (without clearing cache) did not fix it
@enzingerm's solution (enabling "encrypt to verified sessions only" in the room settings, sending a message, and then disabling it) did fix the problem for new messages sent from my iPhone, but did not immediately cause previously sent messages to decrypt.

Triaging the problem was a bit difficult as it was unclear whether the issue was with my ios app or their android app. I initially went to look in the issues for element ios, as the problem seemed to only be happening with messages from my ios device. This is a high impact bug for user trust of E2E in element and can indirectly affect perceptions of other Matrix apps. I appreciate the persistence of whoever is looking into this 🙂

SoftwareSchlosser commented 2 years ago

One thing I noticed is that the "Waiting for this message, this may take a while" message appears on the receiving client as soon as the "...is typing a message..."-notification has been received. So that event is already part of the problem and doesn't get decrypted properly.

morbificagent commented 2 years ago

Same problem here...

Two android phones. Some days it's working some days this message shows up. Sometimes on one or the other phone...

It's not useable at the moment...

morbificagent commented 2 years ago

@enzingerm s Solution does fix this for me too but only for some days and only for the recepients of my messages I think.

And of course I can't switch it on and of always, sent test messages and explain my friends which I have taken with me to Element, that they have to do so 🙄

tomasradej commented 2 years ago

I know the devs probably won't appreciate this, but if anyone needs Element to work right now, FluffyChat doesn't seem to have this problem for me, (any messages that can't be decrypted are decrypted after clicking on them) so you can use that client until this issue is fixed.

pedymaster commented 2 years ago

It happened to me and my wife few days back again. The interesting thing was, she had the problem (Waiting for this message, this may take a while) Only when I wrote her from linux element. If I send the message from windows element or android element, it was OK. Issue disappeared after about two days. Just pointing out that the source of the message might play some role as well

Wife's client was Element for Android Mine's client were Element for Linux (arch), Windows 10 and Android as well

sorry I did not catch the versions, but we keep everything updated so something recent

BillCarsonFr commented 2 years ago

It happened to me and my wife few days back again. The interesting thing was, she had the problem (Waiting for this message, this may take a while) Only when I wrote her from linux element. If I send the message from windows element or android element, it was OK. Issue disappeared after about two days. Just pointing out that the source of the message might play some role as well

Wife's client was Element for Android Mine's client were Element for Linux (arch), Windows 10 and Android as well

sorry I did not catch the versions, but we keep everything updated so something recent

Hello, What would help us the best is that you send a bug report (rageshake) from your element for linux (the one sending messages that can't be decrypted), as well as from the receiver device; just after the problem occurs.

To send a rageshake, you can go to settings feedbacks or type /rageshake in the chat composer.

Meanwhile from your Element Linux you can type /discardsessoin to restart a new session for future messages

morbificagent commented 2 years ago

Here its not about the sending device as the message can be decrypted at the receiver Webinterface and the receiver windows desktop app but not from his android app.

Like this: (Sender) Sending message from element.io Webinterface or his android app -> (Receiver) can read it in his element.io Webinterface -> (same Receiver) gets "Waiting for this message, this may take a while" in the android elements app

Have opened a call @element.io for this..

ggogel commented 2 years ago

Here its not about the sending device as the message can be encrypted at the receiver Webinterface and the receiver windows desktop app but not from the android app.

Like this: (Sender) Sending message from element.io Webinterface or his android app -> (Receiver) can read it in his element.io Webinterface -> (Receiver) gets "Waiting for this message, this may take a while" in the android alements app

Have opened a call @element.io for this..

No, we can't be sure about that. The sending client might actually not exchange the keys or the receiving device might not be able to process them somehow. Only because it works on one receiving device it doesn't mean that the bug is on the receiving side.

morbificagent commented 2 years ago

No, we can't be sure about that. The sending client might actually not exchange the keys or the receiving device might not be able to process them somehow. Only because it works on one receiving device it doesn't mean that the bug is on the receiving side.

Only if the element.io webinterface has the same bug, as messages sent from there are problematic in the android app (receiver) too... Or do i misunderstand something here?

BillCarsonFr commented 2 years ago

If you are curious you can have more details here -> https://www.youtube.com/watch?v=QSeVHiN1dJE

But the sender part is always very important. We have to know if the sender sent the room_key to the receiver, and if not why? Is it because he thinks the receiver is not in the room? or that he can't establish the secure olm channel to distribute the key (no more one time key? / blocked?) ?

From the sender logs we can conduct investigations. From the receiver there is not much we can do.

morbificagent commented 2 years ago

@BillCarsonFr Many thanks, i will take a look at it when my normal work is done...

Have sent logs to the support with the given NVT# and waiting for response now hoping the best.

crtxcr commented 2 years ago

I am part of an encrypted group chat. I am using Element on Linux as well as on Android 12

A person there usually sends from mobile (Android), sometimes several messages in a row. Usually, all are being decrypted immediately, except the last one, for which I have to wait on Android.

However, I don't have to wait with the Linux app. It also doesn't make a difference whether the Element desktop was running or not, it appears to always be decrypting the messages without issues.

No such issues on the sender's end though.

Force-stopping element and clearing cache does not help in my case.

evert commented 2 years ago

Just another confirmation of this issue. We specifically have 2 people in a group chat that are running into this issue often. Just them together, everyone else in the same chats doesn't have the problem

equaa commented 2 years ago

Issue happened to me for the 4th time or something along those lines. Tried doing /discardsession and clearing cache on receiving end with no luck (reacted the same as this user). Creating a brand new device (i.e. logging in/out from element web) from the sender solved the issue.

edit with additional information: happened on a group chat with 3 members, the receiver was also on mobile data the whole time. receiver using element android version 1.3.7 / olm version 3.2.4, and sender using element web on firefox/linux. only happened in that specific room; other rooms and dms between the two parties worked fine.

akshaylive commented 2 years ago

I had this issue happen recently with a two-person group. It started as soon as I linked a new web session and used my phone to verify it. Not sure if it's related.

russelldavies commented 2 years ago

I experienced this issue recently between two Android devices and fortunately I was sitting beside the person who was having issues.

I sent a message at 2022-01-13 12:40:23 and noticed it was not decrypting on the other device. I immediately sent two more messages which were undecipherable. I then ran /discardsession on my device and sent a message (at 2022-01-13 12:42:36) which could decrypted.

I exported the key request audit logs on both devices, removed extraneous key requests for other rooms, and cleaned it up a bit. Alice is the sender device and Bob is the receiving device. <session_id_A> is what the first three messages were encrypted with and <session_id_D> is what the fourth, decryptable, message was encrypted with.

Alice:

[2022-01-06 18:55:24.344] m.room_key         from:@alice:homeserver - sessionId:<session_id_A> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-06 18:55:24.344] m.room_key         from:@alice:homeserver - sessionId:<session_id_A> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-06 18:55:24.344] m.room_key         from:@alice:homeserver - sessionId:<session_id_A> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-06 18:55:24.344] m.room_key         from:@alice:homeserver - sessionId:<session_id_A> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-06 18:55:27.793] m.room_key_request from:@bob:homeserver   - reqId:<request_id_A> action:request sessionId: <session_id_A> requestedBy: [Bob Android]
[2022-01-06 18:55:31.102] m.room_key_request from:@bob:homeserver   - reqId:<request_id_A> action:request_cancellation requestedBy: [Bob Android]
[2022-01-08 14:40:53.939] m.room_key         from:@alice:homeserver - sessionId:<session_id_B> roomId:<room_id> dest:me
[2022-01-10 19:46:27.495] m.room_key_request from:@alice:homeserver - reqId:<request_id_B> action:request sessionId: NVCnKXVGJzJBtC9T11+By8OPT1frhgY6PbXYNgbUYtc requestedBy: [Alice Desktop]
[2022-01-10 19:46:29.747] m.room_key_request from:@alice:homeserver - reqId:<request_id_B> action:request_cancellation requestedBy: [Alice Desktop]
[2022-01-11 15:53:46.571] m.room_key         from:@alice:homeserver - sessionId:<session_id_C> roomId:<room_id> dest:me
# `/discardsession` run
[2022-01-13 12:42:35.545] m.room_key         from:@alice:homeserver - sessionId:<session_id_D> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-13 12:42:35.545] m.room_key         from:@alice:homeserver - sessionId:<session_id_D> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-13 12:42:35.545] m.room_key         from:@alice:homeserver - sessionId:<session_id_D> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-13 12:42:35.545] m.room_key         from:@alice:homeserver - sessionId:<session_id_D> roomId:<room_id> dest:@bob:homeserver|[Bob Android]
[2022-01-13 12:42:35.545] m.room_key         from:@alice:homeserver - sessionId:<session_id_D> roomId:<room_id> dest:@bob:homeserver|[Bob Android]

Bob:

[2022-01-06 18:55:27.673] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_A> action:request sessionId: <session_id_A> requestedBy: [Bob Android]
[2022-01-06 18:55:32.030] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_A> action:request_cancellation requestedBy: [Bob Android]
[2022-01-06 18:55:32.522] m.room_key           from:@alice:homeserver - sessionId:<session_id_A> roomId:<room_id> dest:me
[2022-01-06 18:55:32.522] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_A> action:request sessionId: <session_id_A> requestedBy: [Bob Android]
[2022-01-06 18:55:32.522] m.forwarded_room_key from:@alice:homeserver - sessionId:<session_id_A> From Device (sender key):<sender_key>
[2022-01-06 18:55:32.598] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_A> action:request_cancellation requestedBy: [Bob Android]
[2022-01-08 14:43:02.931] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_C> action:request sessionId: <session_id_B> requestedBy: [Bob Android]
[2022-01-08 14:43:03.251] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_C> action:request_cancellation requestedBy: [Bob Android]
[2022-01-08 14:43:03.687] m.room_key           from:@alice:homeserver - sessionId:<session_id_B> roomId:<room_id> dest:me
[2022-01-08 14:47:41.211] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_C> action:request sessionId: <session_id_B> requestedBy: [Bob Android]
[2022-01-08 14:47:41.211] m.forwarded_room_key from:@alice:homeserver - sessionId:<session_id_B> From Device (sender key):qTGr1CpayjSGzA2FXq0aCc2oDieL8hKLgTi3fkH7XDk
[2022-01-08 14:47:41.211] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_C> action:request_cancellation requestedBy: [Bob Android]
[2022-01-08 16:53:58.917] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_D> action:request sessionId: <session_id_B> requestedBy: [Bob Web]
[2022-01-08 16:53:58.917] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_E> action:request sessionId: YXhNHUOwtAXmh/qCl4bsK01kcwuZXHM8Q9J6eHplzyc requestedBy: [Bob Web]
[2022-01-08 16:53:58.917] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_E> action:request_cancellation requestedBy: [Bob Web]
[2022-01-08 16:53:58.917] m.room_key_request   from:@bob:homeserver   - reqId:<request_id_D> action:request_cancellation requestedBy: [Bob Web]
[2022-01-11 15:52:40.349] m.room_key           from:@alice:homeserver - sessionId:<session_id_C> roomId:<room_id> dest:me
# Messages decrypted again
[2022-01-13 12:42:35.197] m.room_key           from:@alice:homeserver - sessionId:<session_id_D> roomId:<room_id> dest:me

morbificagent commented 2 years ago

Many thanks... i was trying to reproduce this problem too since 2 weeks for generating logs from sender and receiver without luck.

Great you made it.

Hoping that someone can see the problem in it.

KeenMaron commented 2 years ago

Same issue here. Partner receives pictures but my text messages produce the same problem as described in the topic.

Bug-Ninja commented 2 years ago

Same thing is happening to me on Android. I am completely new to Matrix, so I installed Element from F-droid 1.3.18 [40103180] (F-e5874e43). I created a new account in the matrix.org server. After email verification I joined 2 rooms. I can see names, avatars, thumbs up and messages of people leaving the room. When I tap one the messages, it says the encryption keys weren't properly sent to me.

IMG_20220214_163559

Just to make clear: I have not logged in on any other client before. Out if curiousity I logged in in the browser, had to verify my session in the android app en there I saw I couldn't see messages before a specific point in time. Is it an error or is this a setting in the room that new members can't see previous messages? In the last case I guess this should be implemented in a more user friendly way in the Android app.

jm-github commented 2 years ago

The problem just occured to me. The message is not displayed in the conversation, but was displayed well in the notification.

yajo commented 2 years ago

I resetted the keys backup in my desktop element. Waited until all keys were backed up. Then, restored those in the phone. It worked.

heini commented 2 years ago

@Yajo, were you the one on the sending or on the receiving side?

yajo commented 2 years ago

Receiving

egtann commented 2 years ago

This is happening to me in a 2-person group chat, one person on iOS (sending) and another on Android (receiving). The messages do tend to come through but after several hours of "waiting for this message". Completely reinstalling fixed it.

morbificagent commented 2 years ago

Never ending story.... I am using another client now. It's a shame that this couldn't be resolved until today.

Arent the element developer using their own client?

dead10ck commented 2 years ago

It's a shame that this couldn't be resolved until today.

@morbificagent "until today"? Was this fixed?

morbificagent commented 2 years ago

Oh I'm sorry. It was only my bad English. It isn't fixed I think.

wytchmaster commented 2 years ago

https://www.encrypted.at/element-matrix-chat-fix-waiting-for-this-message-this-may-take-a-while/ works for me

dodedodo commented 2 years ago

For those wondering, wytchmaster is talking about the /discardsession command. This has already been discussed a couple of times. It does not seem to work for everyone. The article itself actually points back to this comment

eTomte commented 2 years ago

This just happened to me again today, after not happening for six months. the /discardsession workaround worked again, but I'm on latest synapse and latest Play store android client, and still happening.

iT3E commented 2 years ago

Similarly to eTomte, this issue again happened to me today after being dormant for 6+ months. Only seeing this on the Android client, and the client along with synapse are on the latest version.

NHAS commented 2 years ago

None of these solutions worked. I have to logout and log back in to my account each time. And it reoccurs frequently making matrix borderline unusable. I use this every day, on the latest version of element and synapse.

austinbutler commented 2 years ago

Happened to me again today. Android to Android (both Element).

Periodically I consider moving friends from Messenger and Google Chat to Element, but core critical issues like this remind me it's not ready yet. I can deal with lack of polish and little fun UI features that Element lacks compared to the competition, but messages not being delivered is a complete deal breaker. Yet this issue appears to be tagged with "papercuts." And it appears to be being treated as a papercut. It's not. It's a core function and it's critical.

austinbutler commented 2 years ago

If there's someone at Element that needs someone technical to reach out to for logs I'll volunteer my time.

jm-github commented 2 years ago

Happening again to another contact in an encrypted room, on Android phone. The message shows well in the notification, but not in the room itself. The message only shows well when the same contact sends another message, which is then not readable.

I also volunteer to help fixing this bug. Maybe we could first create an encrypted room to try reproducing it?

morbificagent commented 2 years ago

I have a call open now for month. And the only thing which is happening is that i was asked for logs one time. Now i receive Mails every month with the question if the problem is resolved... NO IT ISNT. But it looks like nobody knows whats the Problem or what to do now. Arent they using their own product?

Instead of throwing all energy in getting element stable and useable i receive app-updates with "a new audio-player"... WTF?

So @austinbutler you are right.

Element isnt ready.

BillCarsonFr commented 2 years ago

Hello, here is a link to the global issue tracking decryption problems https://github.com/vector-im/element-meta/issues/245

You can find more details about this issue there. The important part is that in order to debug an issue we need the logs from both the sender and recipient (see linked issue to see how to submit debug logs).

Several root causes have been fixed, and more are going to be fixed with time. Complete bug reports with both debug logs are helping a lot, thx again.

BillCarsonFr commented 2 years ago

Hello @jm-github , did you sent a rageshake?

austinbutler commented 2 years ago

Thanks @BillCarsonFr. Just submitted bug reports from both sender and receiver.

BillCarsonFr commented 2 years ago

Thanks @BillCarsonFr. Just submitted bug reports from both sender and receiver.

THx got them.

jm-github commented 2 years ago

Hello @jm-github , did you sent a rageshake?

The bug is not happening on my side. I will try to ask the 2 persons involved in the bug to send one

jm-github commented 2 years ago

Hello @jm-github , did you sent a rageshake?

You should have received another pair of rageshakes. I hope it will help

austinbutler commented 2 years ago

This has cropped up every I dunno 6 months or so for a few messages at a time so it was more tolerable, but since I posted 3 days ago the issue is happening to me very frequently. This is the worst it has been, Element is now not usable for me. Weirdly it works perfectly fine when I view the exact same message on desktop (just after it was sent). I also don't get a notification for these "waiting" messages, so I don't even get notified someone tried to contact me. I wonder how the explanation of "encryption keys were not properly sent to you" makes sense given the same sender's messages show up just fine on desktop?

Anyone else having this issue show up more frequently since the last week?

lindhe commented 2 years ago

Nope. I haven't had it since November. Strange that it seems so random...

KeenMaron commented 2 years ago

The problem occurs in my synapse network randomly too. From a dev viewpoint it's quite hard bug. There must be a way to systematically provoke the bug. Random occurring bugs are a nightmare...

morbificagent commented 2 years ago

Have you @BillCarsonFr and/or the Crypto-team found something in the last logs sent? Would be great to get informed here about the results to get the feeling someone is working on this.

I have bought the service/vserver or whatever from element.io and thought i would get some sort of "premium messenger" and now i have to use it with the matrix-client "FluffyChat" (man i hate this name ;-) ) because of the official element client isnt working on mobile devices.

Sorry this isn't helpful but it's so annoying...

austinbutler commented 2 years ago

Yeah still happening for me. Literally have five "Waiting for this message" in Element Android while simultaneously looking at the encrypted version of those same messages on Element Desktop and FluffyChat Android. So I can confirm that FluffyChat is a good workaround. If it's a server issue (note I am using matrix.org), then it's a server issue that everything else handles just fine and Element Android does not.

element-hq / element-android

Waiting for this message, this may take a while. #1721