element-hq / element-ios

A glossy Matrix collaboration client for iOS
https://element.io
Apache License 2.0
1.72k stars 479 forks source link

Messages failed to send, and delete retry button warning get stuck ⚠️ #6344

Open toshanmugaraj opened 2 years ago

toshanmugaraj commented 2 years ago

Steps to reproduce

  1. At some random scenarios when there is no cell data.

  2. When message got failed to be send

  3. We get the below alert:
    alert

  4. This alert got stuck and doesn't disappear even when we click delete button or retry button or app is force killed.

Outcome

The delete button should clear the message data and the warning should get clear

But when there is no cell data, the warnings doesn't disappear after deleting or retry button clicked.

Trying force kill the app doesn't clear the warning too.

Your phone model

iPhone 11

Operating system version

14.8

Application version

1.8.19

Homeserver

matrix.org

Will you send logs?

No

cosminribo commented 1 year ago

I am also affected by the same problem. Android 12, Element 1.5.4, matrix.org.

Fenisu commented 1 year ago

I have seen this issue on Android too. With 2 different accounts on two different devices with different Android 10 and Android 13, on the same server with same Android app version 1.5.8, server 1.70.0 to 1.73.0

Fenisu commented 1 year ago

A very ugly workaround is to reset the app and add the account again...

beeforbacon commented 1 year ago

I am experiencing this bug on android Any fixes?

afonsofrancof commented 1 year ago

My partner is also experiencing this bug on android. My server was down for a bit, and now that it's back up, she still has that error message that she can't delete.

All her messages arrive encrypted and I get the encryption error.

** Unable to decrypt: The sender's session has not sent us the keys for this message. **
Re-request encryption keys from your other sessions.
Fenisu commented 1 year ago

Maybe this is a server issue and should be reported in the synapse project.

n1trux commented 1 year ago

Maybe this is a server issue

Why would it be when it goes away after resetting the client and it also goes away if you're using a different client? This issue only happens when Element loses connectivity to a server or the server itself is down and it can't send messages for a while or the server itself is reachable but the chat isn't.

Other messengers show other bugs when they're not connected to the server, but this also happens on Dendrite. If there's anything wrong with these servers, there might be something wrong in the spec.

Oh wait, the spec v1.6 says in 11.2.2.1 "Recommendations when sending messages":

In the event of send failure, clients SHOULD retry requests using an exponential-backoff algorithm for a certain amount of time T. It is recommended that T is no longer than 5 minutes. After this time, the client should stop retrying and mark the message as “unsent”. Users should be able to manually resend unsent messages.

So Element, by not allowing to manually resend unsent messages, doesn't fulfill this optional requirement. It certainly doesn't stop trying to send messages either if they're visible in the message list.

In fact, this doesn't only happen for unsent messages either. It also happens for unsent redaction events, unsent membership change events (e.g. kicking a user) and others in my experience. This still happens with Android v1.5.28 and Synapse 1.80 as well as Dendrite v0.12.

This is clearly a local, Element-only issue.

@stefanceriu if you can't reproduce this, try filling up Synapse's disk so it can't write any more information to the database. This leaves Synapse in an undefined state. The clients will still be able to connect, but won't be able to send messages to some rooms. If you send and redact lots of messages, I'm pretty certain you will run into this bug.

Basically, to reproduce this you have to break the server. If you don't have tests which break the server, try to find ways to do it and come up with a proper integration test.

jacotec commented 1 year ago

I'm seeing this even without breaking the server. Had this several times - even if that particular message has been sent and is visible by other users in the chat.

image

In the picture above every message was sent, and even read by the other side. And suddenly the "was not sent" messages appeared.

This is very annoying for users, especially as hitting the green "Repeat" button simply does nothing (I guess because the message was already sent). So you need to hit the waste icon (which is not a good way if the message was really not sent).

chrysn commented 1 year ago

Is there any known workaround that is less disruptive than re-installing the app (and hoping all history and keys recover well)? In particular, when there is no message-with-an-exclamation-mark around that is the "culprit"? (In my case, this likely happened during location live sharing last Sunday on matrix.org; deleting that location sharing event had no effect on the error message).

comk22 commented 7 months ago

I solved this by hitting the three dots top right in the android app and selecting "do an optimized init sync".

zerobulfa commented 7 months ago

I solved this by hitting the three dots top right in the android app and selecting "do an optimized init sync".

Works for me in Android, but you have to enable before the Dev Mode and u will find it in the room overview - not directly in the one that shows the error. Thanks @comk22

SirCypher commented 6 months ago

I received this exact error on the android version of the app. Nothing happens when trying the options to delete or retry. Tried force-stop + deleting cache but that did not help either. Seems like the error is stuck on screen forever.

As a workaround the previously mentioned dev mode + "optimized init sync" fixed this issue. Thanks a lot @comk22 and @zerobulfa !

sevenrats commented 3 months ago

i got very frustrated with this on Element Desktop on linux, but after Element throttled my cpu up to several hundred percent for several minutes with an unresponsive ui, i was able to "delete all" seemed very much like it wasn't going to make it, but ultimately did.