Waiting for this message, this may take a while.

[532910]

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.

[532910]

Trying to re-verify (Secure Backup -> Set up on this device) this phone gives:

via QR code both devices shows error:

via image set the phone shows:

riot-web says:

Verify other session
Verification cancelled

You cancelled verification. Start verification again from the notification.
[Clear]

[532910]

Restoring messages from backup decrypts all messages. Newly received messages after backup recovery are shown as Waiting for this message, this may take a while. Restoring messages from backup again decrypts all messages, even just received before this restore.

[532910]

Is any update there? It's completely impossible to use Element after upgrade!

[532910]

Right now, after restoring messages from backup it says:

Cross-Signing is enabled
Private Keys on device

But still shows new messages as Waiting for this message, this may take a while

[jtrees]

I know someone who also gets the Waiting for this message, this may take a while message a lot. It can take several hours for the messages to resolve but they eventually do.

[532910]

Nothing has changed after more than a week of waiting, so I had to reinstall Element.

[PureTryOut]

My parents have the same issue when talking between them. They do resolve after 24 hours or more, but of course that makes it impossible to have a proper conversation. Please give this issue some priority, beside the vague text it's more than just an UX bug!

[BillCarsonFr]

Hello, can you please give more information on the element version of both devices?

Also could you check the security settings on both devices (is Encrypt to verified session only is ON?)

Do you have other sessions?
The fact that key backup import is able to decrypt could mean that your other session are getting the keys and uploading them to backup.
So it could be possible that your device is not getting the keys.

Go to settings > Advanced > and enable developper mode, this will allow you to see more about the error, if you go back to the room, what do you see for the errors?

Did you submit some rageshake (top righ button in home screen > report bug; add reference to issue matrix-org/matrix-spec-proposals#1607 ?

[PureTryOut]

Speaking for my parents here, as I don't have this issue myself.

They use the latest version from the Google Play store, so whatever version that is. They don't have "Encrypt to verified session only" on.
They have other sessions, for both a tablet and a laptop (so webbrowser) at least.

I'll ask them to enable developer mode and submit a rageshake. Thanks for looking in to it!

[532910]

element version

the latest available on GPlay

Encrypt to verified session only is OFF.

have other sessions?

Yes.

[MrCustomizer]

A few users on my server have reported this issue to me. Seems like this is still happening. Any news on workarounds/solutions?

[aczerniak]

It happened to me today after I cleared cache on Element installed on Android phone. I use Element 1.0.9[40100092]. In developer mode message says that sender's device didn't send keys. Before I cleared cache those messages were properly decrypted. I have 4 sessions (3x Firefox and one phone - the issue affected phone only), 2 of them are open and devices that were used sent affected messages are also on so at very least they should resent needed keys.

I don't have cross signing enabled. I verify all session manually.

[thomashoullier]

Here on matrix-synapse-py3 1.22.1 (server), a user on the android client (update 19 Oct 2020) reported the same problem.
"Waiting for this message, this might take a while" for all the messages from a particular user starting at some date in e2e encrypted channels. The user with the bug can still receive messages from other users on the same channels.

[lasselin]

A user just reported me this issue on the matrix.org server.

[akallabeth]

Have the same issue from time to time with different users (and some small group chats).
This did not happen with 1.0.8 and earlier (all from F-Droid)
All accounts on matrix.org.

[austinbutler]

Getting this for the first time today. Didn't change anything and was working fine yesterday. Encrypt to verified sessions only is off.

[gtirloni]

I'm getting this one a newly activated device after I did the cross-sign verification (Element Android 1.0.11 [40100112] (G-b847)).

[smeyersdev]

My wife also runs into this bug on her Element installation on Android (Play Store). There is a strange behavior: As long as she stays at home connected to Wifi network, the issue does not appear. But as soon as the smartphone is using mobile LTE internet, it happened several times that I received these messages from her which never got decrypted.

[jrozanski]

Indeed @smeyersdev, I observed the same behaviour sporadically on poor quality connections. It appears to be related to instability of the connection.

[dalcde]

This seems to depend on the session sending the message. In one of my conversations, I have interleaving messages from different devices (same user), and only the messages from one of the devices are stuck in "Waiting for this message, this may take a while".

[dalcde]

I'd imagine the issue starts with an attempt to retrieve a key failing. What is the retry strategy in this case? In other parts of the matrix ecosystem I've had issues with exponential back-offs leading to long delays when something is inaccessible.

[michel-slm]

I'm seeing this too, and the weird thing is:

• it happens with messages from one user to a group with multiple users
• messages from other users are fine
• messages from this user only get delayed on one of my Android phones (Pixel 3, Android 12 beta 2) but not on the other (Pixel 5, Android 11)
• this only started today, previously both phones are fine
• 1:1 messages with this user is fine on both phones
  We tried verifying our sessions, it does not seem to have any effect. And once they send further messages, the previously "waiting" messages seem to clear up, but that means I'm always unable to see their last message on this thread.

[Wodann]

I'm consistently seeing this issue on my android phone (works fine in my desktop browser's session) for the last message sent by one user. The moment they send more messages, the message that previously displayed the error will become visible, but the new latest message will report the error instead.

I've tried clearing the cache, but to no avail.

[jzacsh]

regarding the theory about mobile connectivity being the root cause: while I am seeing a correlation with mobile (non-wifi) usage, I think the bigger problem is the undefined behavior from then on.

That is, the last couple times I hit this bug, I then had trouble working around it. For example we'd see these steps:

1. hit the bug in 1:1 encrypted chat, while out on mobile connection
2. both parties jump onto same (fast) wifi LAN
   1. both keep trying to send chats
   2. both showing phones in person (one person has all messages rendered, the other sees the bug on messages -2, -3, -4 (but 0, -1 sent over wifi are fine))
3. give up on element for a day or so
4. over a day later one person reports (via Signal) that some of the messages are suddenly showing

step (2) involves both parties having their Element app out, actively looking at the same 1:1 room in the foreground on Android, actively connected on a fast wifi connection. So:

• a) if it is failed request (needing retry), perhaps this is popping up due to a retry bug?
• b) Or perhaps this is a ux issue? (eg just need to add a "retry now [i promise i'm on good connection now]"?)

[agherzan]

I have the same issue: iPhone client vs Android client. Only some of the messages from iPhone end up in the "waiting" state on the Android side. What I saw, is that sending more messages starts to refresh previous messages in this state. In other words, the last message is always in "waiting" and receiving more messages unlocks it while locking the next one. It also happens only with this iPhone user. I have chat rooms, with clients on exactly same platform and room configuration where this doesn't reproduce ever.

[7underlines]

Project says it's frozen

They moved to GitLab https://gitlab.com/famedly/fluffychat

[red0888]

Have the same issue, this is unacceptable and terrible!

[JokerGermany]

It's important to tell if you use Version 1.6.2 and therefore the new rust crypto

[KeenMaron]

Since when is this update out ? On the android app store the last version is from 24.04.23 version 1.5.32

[JokerGermany]

Last week
https://github.com/vector-im/element-android/releases/tag/v1.6.2
, but i don't know if it's already in the playstore

Would wait until you have this version and report it again if the error occurs with this version

[austinbutler]

Wow finally! Though the Play Store version is three releases behind. F-Droid, too. I wonder why?

Anyone not wanting to wait should be able to install directly from the releases link above. But the fact that they don't seem to keep the app up to date makes me wonder if they don't consider these releases stable yet?

[austinbutler]

Oh they touch on this in the README: https://github.com/vector-im/element-android/blob/develop/README.md#releases-to-app-stores

[KeenMaron]

So how long do we have to wait until it is published in the Playstore?

[benmordecai]

@KeenMaron that is addressed in the README above. It's an indefinite amount of time because Google is unpredictable with how long it takes to approve updates.

[JokerGermany]

Perhaps its another story:
https://matrix.to/#/!AZozoWghOYSIAfaZjJ:matrix.org/$1AwZxtcePbIXxxyfMx5NKNCwcqrSm4VZ441-jCKQz7U?via=matrix.org&via=tchncs.de&via=envs.net

don't know about the beta channel, but stable is at 1.5.32 on the Play Store. AFAIK there are still some performance issues with 1.6.2, so I presume that's what is holding up the release (I'm just a lurker though, I'm not involved with development in any way).

[RussellAult]

It's important to tell if you use Version 1.6.2 and therefore the new rust crypto

I just ran into this issue again (for the first time in a while) on 1.6.3 from the Play Store, so the new Rust crypto hasn't totally resolved it. I'm not sure if it's related, but the client in question was also suffering from #6490 , which I resolved by enabling cross-signing (even though the user only ever uses the one client).

[aelmahmoudy]

Why isn't it on F-Droid ?

[benmordecai]

@RussellAult - is your device producing the messages that fail to decrypt on other users devices? My experience is that 1.6.2 fixed the problem of users creating messages that fail to decrypt but users who have not updated still may produce messages that fail to decrypt when read from a 1.6.2+ device

[RussellAult]

@RussellAult - is your device producing the messages that fail to decrypt on other users devices? My experience is that 1.6.2 fixed the problem of users creating messages that fail to decrypt but users who have not updated still may produce messages that fail to decrypt when read from a 1.6.2+ device

Ah, interesting. The message that failed to decrypt was sent by me from the nheko client v0.10.2 (i.e. the latest version available in Debian's oldstable-backports); this is a bit behind the current release version (0.11.3), but I'm not seeing anything in the release notes that would indicate a major change in the way it handles encryption. Having said that, my messages from nheko are showing up on my phone as "The authenticity of this encrypted message can't be guaranteed on this device" despite the session showing up as "Trusted", so clearly something is up.

[KeenMaron]

I'm hosting a Matrix server, and this issue appeared quite often when some users had a bad internet connection. But luckily, we haven't had any problems for a few months.
Now we have all updated to the latest Android version (1.6.3) hoping this issue will never appear again. One user is using an iPhone, and the Element version is 1.10.14. Out of nowhere, the issue appeared again. His messages are unreadable in one room (can't be encrypted). The funny thing is, direct chat works, and chatting with him in other rooms works as well. How can we fix it?

[KeenMaron]

That's the metadata of the message which cannot be decrypted. Is there any chance to get this fixed, or must I delete the whole room and create a new one?

[CKwan-hub]

Encountering the same issue on newest version

[rajil]

I was hit by this in 1.6.3 version, sign out/in, import of recovery key did not fix the problem. New messages are now coming in but old messages still have 'waiting message'.

[Tecol87]

Are there any production ready alternatives?

[zoj613]

I've been having this issue where this message has been showing for months on one of my devices. No matter how long I wait it is still showing after months and therefore cannot read earlier messages prior to installing the app on the devices even after successful verification. I'm using version 1.5.32

[svenb1234]

You can try to restore the keys from settings > security and privacy > restore keys. That helped for someone who was stuck after an update to 1.6.3 and the new encryption thingy. While all others had a second session with which they could very the new session created by the rust encryption and 1.6.3, the users with only a single session are stuck.

[zoj613]

You can try to restore the keys from settings > security and privacy > restore keys. That helped for someone who was stuck after an update to 1.6.3 and the new encryption thingy. While all others had a second session with which they could very the new session created by the rust encryption and 1.6.3, the users with only a single session are stuck.

That worked like a charm. Thank you!

[pedymaster]

Sunce about 3 weeks ago, this happens to me, my wife and several other friends way more often. Like 10 times nore often
Currently on element android 1.6.3 with rust sdk 0.6.0

[saschanaz]

For me the restore keys way didn't work, but somehow logging in and verifying on another device magically fixed the issue on the existing login session.

[Tecol87]

Since 1.6.5, I haven't had any issues anymore.

[ismay]

I encountered this whilst being logged in to element android, element web and android fluffychat (all the same account). I had already uninstalled fluffychat. Ending the fluffychat session via element web's session management UI resolved this bug for me.

Might be worth checking if you have stale sessions and killing them if you encounter this bug. Seemed to fix it for me.

[richvdh]

Duplicate of element-hq/element-meta#245