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.

[theduke]

I also recently stumbled over this a week ago after switching to a new phone.

This is a serious dealbreaker and I regularly see it mentioned in various discussion channels, like Hackernews, so it is definitely a regular occurrence.

I'm quite disappointed that this isn't receiving more attention.

[anoadragon453]

Hey all - thanks for sending in your reports. As a result, we noticed a serious regression in Synapse v1.38.0 which caused Element Android to have a significantly higher chance of running into decryption issues.

The issue is now fixed with Synapse v1.38.1, which was released on Thursday. The upcoming Synapse v1.39.0 will fix another long-standing encryption bug which could sometimes cause decryption issues on various clients, including Element Android. As these new versions are rolled out to the federation, encryption issues should become less and less frequent.

We're still tracking down the edge cases though -- as a reminder, the best way to help debug encryption issues when they pop up is to hit the "Submit Debug Logs" from settings (or shake your phone) on any devices that were affected. This allows us to get a clearer picture of why keys didn't arrive or failed to send. Thanks!

[jzacsh]

@anoadragon453 thanks for the update. Your reminder, while it might seem obvious, is actually quite helpful to hear. Specifically, I personally hadn't submitted logs in a while, because (in my imagination) no one with logs-access was actively looking into this bug and thus no one analyzing said submissions. I'll start sending again 👍

(to clarify, in my experience, often such log submissions have a TTL of retention before they're autodeleted, so I was picturing all the comments here by end-users would be accompanied with logs that would be long-since autodeleted by the time someone came along to try to investigate)

[bahur142]

It happens again. With Element 1.1.4 on Synapse 1.39.0

Edit: All in the group (except one), are using Element Android and they cant see the messages. One of the members is with iPhone and after request a keys from the sender, the messages became visible for him. But after /discardsession command from the senders side is OK now for all members.

[austinbutler]

@anoadragon453 when should we expect this fix to be rolled out to Element servers? I'm having this issue today.

[austinbutler]

I'm well over 24 hours and still have the message on a particular incoming message on my phone. Element Desktop sees the message just fine.

[anoadragon453]

@austinbutler The fixes mentioned above have been rolled out to matrix.org and all EMS servers for at least a week. If you are seeing further issues with encryption, I recommend submitting debug logs from both affected clients and tagging this issue in your report so we can have a look -- it's likely to be something other than what was addressed with the above PRs.

[austinbutler]

@anoadragon453 sent.

[dead10ck]

I still see this message on the latest Element on matrix.org. I sent a bug report

[matrixes]

I still see this message on the latest Element and our own selfhosted Matrix server that we updated today (to 1.40.0) and latest clients.

The only discernible patterns I can see is that I'm using Element Android and my buddy is using the Element iOS client, and that's the only chat that has this issue. All others, be it Android<->Web or Web<->Web or Anything<->Anything except Android<->iOS, work without a hitch.

I've sent a bug report (but missed mentioning this ticket number... ugh). It's about time we figure out a way to squash it once and for all.

I'm willing to do tests and whatnot to move this issue forward to its final resolve.

[PxEclipse]

Had this issue often in the past in one on one conversations and private rooms. Today it happened again. The only fix is /upgraderoom. Android to android communication on matrix.org. I appreciate the effort and that element exists. But for me and the people I use it with, it's not in a usable state.

[dontezuma]

We have a server and have identified the same problem. My desktop client displays all messages correctly, but when my partner sends a message through his iPhone, it displays the message. When he sends via laptop, it also displays immediately on the phone.

So, as is clear from prior posts, this is strictly an issue when someone sends messages FROM and iPhone TO an Android.

I say this to recommend maybe retitling the bug to be more specific.

[russelldavies]

I just started seeing this in a room of three participants, all Android devices. I think it happens when there is poor network connectivity and the device sending the message also has to rekey and the new keys are delayed in sending.

[dontezuma]

I'd agree with that assessment, but every message from my partner's iPhone have had this delay, even when he's not in a degraded connectivity situation. Of course, these are not mutually exclusive. That could very well be happening, and it's a separate cause of the same issue.

[9ler]

Thanks a million for making this software <3 I am seeing this problem as well. On androide phones (androide 10) also when they are on ok WIFI and on the same network as the synaps server. But for some reason its only from one device to the other, not both ways.

[florian6973]

Hi! I have a e2ee room with 4 family members. My mum is seeing this message and it is very problematic. I helped her update Element on Android, clear the cache, but nothing has changed. Is there a fix to this error ? Thanks.

[SoftwareSchlosser]

Same problem here. Sending from Android to Android + desktop app. The desktop app always shows the messages but the receiving android app doesn't.

[qtip]

I have been seeing this problem for several days now on my android phone. The web app works fine but the android app shows the message.

Edit: This stopped being an issue for me sometime after I posted this message.

[tomasradej]

Update: I was seeing this message in one specific channel (a p2p with one user). We have closed that channel and opened a new one, and I haven't had this problem since.

[dawnmew]

This is CRITICAL. How is this not fixed yet? It's stopping people from seeing each others' DMs... I rely on my phone when I'm out, and this is now the single showstopping bug preventing me from thinking of Element as reliable. I've only started seeing this in the last month or two, but my friends are seeing it too. This is horrific. Do something...?

[zopieux]

@dawnmew Please review some basic etiquette materials for interacting with open source initiatives. Thanks.

[eTomte]

This issue just happened to me in a 1:1 conversation today. Messages I sent from Desktop client would give the "Waiting for this message" error on the recipients Android phone on Element. He could see the same messages when using Element Desktop.

[tomasradej]

I have encountered the problem again in a room with multiple people and a different 1:1 chat.

[enzingerm]

I had the same problem with two Android clients, A and B, on version 1.3.1 and Synapse 1.43.0. Always the latest few messages from A to B couldn't be decrypted and it showed "Waiting for this message..." (this was not the case for messages from B to A). Over the course of the next hours the messages would be resolved.

I enabled "Encrypt to verified sessions only" in the settings of A, sent a message, and disabled the option again. Since that, messages can be decrypted immediately on B. Maybe this helps others, or gives the devs a hint what might be the root cause...

[meyerrj]

I'm encountering this error again now, too. It had been several months since it was an issue, but now it seems to be completely at random.

[dontezuma]

What’s odd, is after a reinstall, I got all my messages showing and have not sseen this issue since. Not sure what screwed up the keys in the first place, but it resolved itself…

Anyone else have it resolve itself? Maybe give the rest of the reporters some hope?

Don

From: Richard Meyer @.> Sent: Monday, October 11, 2021 8:21 PM To: vector-im/element-android @.> Cc: dontezuma @.>; Comment @.> Subject: Re: [vector-im/element-android] Waiting for this message, this may take a while. (#1721)

I'm encountering this error again now, too. It had been several months since it was an issue, but now it seems to be completely at random.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vector-im/element-android/issues/1721#issuecomment-940550221 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ALGED5VCQI7CTF2SWPB6DHDUGN5NRANCNFSM4O7HMMCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

[hannobraun]

Anyone else have it resolve itself? Maybe give the rest of the reporters some hope?

It did resolve itself for me, and I didn't even do anything except send a bug report each time I saw it. Maybe someone from Element nudged something in the background (my homeserver is hosted by them), or maybe it really cleared itself up somehow.

[dead10ck]

It has not resolved itself for me

[frederictobiasc]

Anyone else have it resolve itself? Maybe give the rest of the reporters some hope?

It did resolve itself for me, and I didn't even do anything except send a bug report each time I saw it. Maybe someone from Element nudged something in the background (my homeserver is hosted by them), or maybe it really cleared itself up somehow.

Same, after sending the bug report, the problem was magically resolved.

[melroy89]

An Android user (using my synapse server), experience the same problem on her client-side. She gave me this screenshot of her phone, showing the problem:

[ggogel]

This issue appeared for me several days ago when sending from Element Android to Element Android in one direct chat. Error in dev mode reads:

** Unable to decrypt: OLM **

The message decrypts without errors on Element Web. Further, this only occurs randomly with some messages.

[SoftwareSchlosser]

For me this also didn't happen anymore for some time. Seems like there has been made at least some improvement.

[ggogel]

I've deleted app data and reconfigured it. This seems to have fixed the issue for now...

[ggogel]

The issue occurred again for two different users, sending from Element Android to Element Android. I can confirm that it's always the last message that can't be decrypted.

[antibios]

upvote.

Android to android messages take hours to decrypt. Both Element clients. Element-desktop decrypts the messages instantly.

I've reported the bug in app and sent key request history for troubleshooting. Please contact me if you need more detail.

[stukev]

I can confirm that the solution of @enzingerm is working in my case. For me, I was using the web interface, here the setting is called "Never send encrypted messages to unverified sessions from this device":

Simply enable this option, then send a message in the room that your partner with the problem is in. Now toggle the setting off again, send another message and the problem should be solved.

[meyerrj]

The solution @enzingerm provided did not work for me unfortunately.

I eventually did the sign out, clear all app data, and sign in again approach... and it wasn't until I rebooted my phone after that when everything started working properly. So far no more key sending delays, and its been about 2 days.

[RussellAult]

I just ran into this issue as well (room with only two participants, messages arriving fine in a web browser, messages arriving with the "waiting for message, this may take a while" error showing up in an up-to-date GPlay build). Here's what I've noticed:

• A "Force stop" and re-opening of Element made all previously-received messages decrypt except for the most-recently-received one
• Messages received after the "Force stop" will still show an error, but:
  • Intermittently, the immediately-next-received message after the "Force stop" will decrypt (even though subsequent ones do not)
  • On at least one occasion, the immediately-next-received message showed an error but its arrival caused the previous message (i.e. the last one received before the "Force stop") to decrypt (which seems very strange indeed!)

[vetko]

I can also confirm that the solution of @enzingerm is working in my case ("Never send encrypted messages to unverified sessions from this device" ON -> send message -> OFF).
I have another pair of clients in the same situation, I will try /discardsession as the other way, let's see if that solves it as well.

[kat-co]

https://github.com/vector-im/element-android/issues/1721#issuecomment-880214682

I just experienced this for a second time after months of stability. Running /discardsession worked once again.

[melroy89]

These are still workarounds.. The root cause is still unknown and not resolved.

[aethralis]

I have now encountered the same problem. Afer /discardsession and closing and opening the android app the messages that previously were not displayed are shown. However, if the other user sends me a new message, then I get "Waiting for this message..." again.

[lindhe]

I got this issue now, after the recent update from 1.3.6 to 1.3.7.

[lindhe]

Clearing app data and reverifying fixed it for me. This should really be investigated more so people don't have to get into such a state. I cannot remember ever having to do something similar on Telegram (which admittedly is not e2ee in my case).

[kat-co]

This is a really annoying thing that happens, but I wanted to point out that this bug report is one of those that probably represents a symptom and not a specific bug. This symptom is probably rooted in disparate underlying bugs.

So different things are probably going to fix this for different people, and it's going to collect a lot of "me too, but for me it happened when...". Unfortunately that means it's going to look like the devs are ignoring a critical issue even if they're working on fixing some of the bugs that underpin this. I.e.: you can't fix and close a symptom until you fix all the bugs that cause it.

It's good that everyone has a place to look for ideas, because maybe they're experiencing the same underlying bug. A different strategy might be to report symptoms as: "When I did this, then I started getting this error". That would help segregate the same symptom into buckets of potential root causes.

Just some thoughts. I hate seeing people come to this issue and get frustrated because it looks like it's being ignored. Good luck to you all.

[dead10ck]

At the same time, it only takes a few seconds to report a status update like "I've been searching for the root cause, but I've been having trouble reproducing the issue, so I haven't found it yet."

The best way to avoid the perception of being ignored is to communicate anything at all, even if no real progress has been made.

[tomasradej]

@kat-co That's the problem, I wasn't doing anything at all, it just started happening one day. The only thing I can say to narrow it down is that the room(s) where this happens for me have been unencrypted for a long time and then I enabled encryption, but it still took many months for this problem to manifest.

[zopieux]

As a counter point to the above, in my setup the bug happens in rooms that were always encrypted from there get go, both private messages and group rooms (not that I believe it's any different in the matrix protocol).

[lindhe]

I'm annoyingly good at finding bugs. I'll give it a shot, when I find some time, to reproduce it reliably. It feels to me like it will be possible...

[tomasradej]

@lindhe thank you so much. Can I buy you a beer? (Seriously)