-
Notifications
You must be signed in to change notification settings - Fork 734
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Waiting for this message, this may take a while. #1721
Comments
Restoring messages from backup decrypts all messages. Newly received messages after backup recovery are shown as |
Is any update there? It's completely impossible to use Element after upgrade! |
Right now, after restoring messages from backup it says:
But still shows new messages as |
I know someone who also gets the |
Nothing has changed after more than a week of waiting, so I had to reinstall Element. |
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! |
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? 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 ? |
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. I'll ask them to enable developer mode and submit a rageshake. Thanks for looking in to it! |
the latest available on GPlay Encrypt to verified session only is OFF.
Yes. |
A few users on my server have reported this issue to me. Seems like this is still happening. Any news on workarounds/solutions? |
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. |
Here on |
A user just reported me this issue on the matrix.org server. |
Have the same issue from time to time with different users (and some small group chats). |
I'm getting this one a newly activated device after I did the cross-sign verification (Element Android 1.0.11 [40100112] (G-b847)). |
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. |
Indeed @smeyersdev, I observed the same behaviour sporadically on poor quality connections. It appears to be related to instability of the connection. |
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". |
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. |
I'm seeing this too, and the weird thing is:
|
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. |
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:
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:
|
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. |
They moved to GitLab https://gitlab.com/famedly/fluffychat |
Have the same issue, this is unacceptable and terrible! |
It's important to tell if you use Version 1.6.2 and therefore the new rust crypto |
Since when is this update out ? On the android app store the last version is from 24.04.23 version 1.5.32 |
Last week Would wait until you have this version and report it again if the error occurs with this version |
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? |
Oh they touch on this in the README: https://github.com/vector-im/element-android/blob/develop/README.md#releases-to-app-stores |
So how long do we have to wait until it is published in the Playstore? |
@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. |
Perhaps its another story:
|
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). |
Why isn't it on F-Droid ? |
@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. |
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. |
Encountering the same issue on newest version |
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'. |
Are there any production ready alternatives? |
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 |
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! |
Sunce about 3 weeks ago, this happens to me, my wife and several other friends way more often. Like 10 times nore often |
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. |
Since 1.6.5, I haven't had any issues anymore. |
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. |
Duplicate of element-hq/element-meta#245 |
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.
The text was updated successfully, but these errors were encountered: