Skip to content
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

message stuck "undelivered" at bottom of chat window, without delivery failure notification #13512

Closed
aral-matrix opened this issue May 5, 2020 · 5 comments
Labels

Comments

@aral-matrix
Copy link

Description

Since upgrading to riot 1.6.0, some message deliveries are not correctly acknowledged as delivered, but also do not time out. Other users can see them, and a restart of riot-desktop loads them correctly in the room history. Until the restart, they stay at the bottom of the chat window.

Steps to reproduce

  • send a message in any room
  • bug seems common, but can not be reproduced reliably.

Describe how what happens differs from what you expected.

Expected behavior: Riot should either get a delivery / reception acknowledgement from the home-server, and display the message as part of the chat history - or report a timeout & offer the option to delete / re-send.

I suspect this is showing up at the moment due to heavy load on the matrix homeserver.

Logs being sent: yes/no

Version information

  • Platform: desktop

For the desktop app:

  • OS: Debian
  • Version: 1.6.0
    delivery-bug1
    delivery-bug2
@ara4n
Copy link
Member

ara4n commented May 5, 2020

this is due to a server bug on matrix.org exposed by the huge load explosion we had due to enabling e2ee. closing as dup of matrix-org/synapse#7409 - thanks for filing.

@ara4n ara4n closed this as completed May 5, 2020
@aral-matrix
Copy link
Author

I suspected as much - but I still think there's a "bug" in riot for keeping those messages in "limbo" instead of reporting a delivery failure.. in my humble opinion, low priority, but should be kept on the to-do list...

@t3chguy
Copy link
Member

t3chguy commented May 6, 2020

@aral-matrix well no the issue is the server says successfully accepted the sent event and gives us back an event id but then the event never comes back down sync as it is meant to so we don't know exactly where it fits within the timeline order.

@aral-matrix
Copy link
Author

Okay, that makes sense.. in that case there's no ideal solution for the messenger... Closed it is, then... :)

@Shaping
Copy link

Shaping commented Jan 10, 2022

I too have this problem still. I have one message stuck from several months ago. I have second stuck from a few weeks ago. My business partner has one stuck message in the room we share. The message that is stuck for him is not the same one that is stuck for me.

My Android Element client shows one stuck message. My Windows desktop Element client shows two stuck messages. The one stuck message on Android is neither of the stuck messages on the desktop.

This is one of our main complaints. I'm trying to hold on. He wants to return to Telegram. We like the encryption of Element, but the ergonomics are mediocre to poor. He's not a fan. (The other showstopper for us is the lack of correct/timely notifications. This is fairly simple to do. If the devs here have any doubt about how to do this correctly, do what Tg does; it works. We've seen enough falsely positive notifications from Element to screw up three time-sensitive financial transactions. This is the point at which a user will typically trade back the improved security for less security, in favor of reliable, timely messages that have been acked and do not need to be second guessed about whether they were really acked. In such cases the improved encryption is not as valuable.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants