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

Claimed to have successfully sent e2ee messages... but hadn't. #21992

Closed
ara4n opened this issue Apr 29, 2022 · 3 comments
Closed

Claimed to have successfully sent e2ee messages... but hadn't. #21992

ara4n opened this issue Apr 29, 2022 · 3 comments
Labels
A-E2EE A-Read-Receipts A-Timeline O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@ara4n
Copy link
Member

ara4n commented Apr 29, 2022

Steps to reproduce

  1. Element Web (EW) was incremental syncing after unsleeping after being offline for ~12h
  2. Said server connection was unavailable while it tried to sync
  3. I sent a bunch of messages in an E2EE room
  4. They were shown to be sent (i.e. ticks in circles as RRs)
  5. Restarted the app to try to unstick the sync
  6. They were shown as unsent and hadn't actually sent, despite claiming that they had.

Outcome

What did you expect?

Ticks in circles should mean messages were sent, whatever.

What happened instead?

Messages were not sent.

Operating system

No response

Application version

No response

How did you install the app?

nightly

Homeserver

No response

Will you send logs?

Yes

@ara4n ara4n added the T-Defect label Apr 29, 2022
@duxovni duxovni added S-Major Severely degrades major functionality or product features, with no satisfactory workaround A-Timeline A-Read-Receipts O-Uncommon Most users are unlikely to come across this or unexpected workflow labels May 2, 2022
@duxovni
Copy link
Contributor

duxovni commented May 2, 2022

(Marking as S-Major, because claiming we've sent messages when we haven't is severely misleading to users around core functionality of a messaging app)

@t3chguy
Copy link
Member

t3chguy commented May 3, 2022

I'm not sure this is what it seems, the before-reload log shows the target eventId, which means that it was indeed sent to the server, otherwise we wouldn't know its eventId given it is returned by the server as part of sending a message

@t3chguy
Copy link
Member

t3chguy commented May 15, 2024

Closing due to lack of recurrence and logs not being helpful to reproducing.

@t3chguy t3chguy closed this as completed May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE A-Read-Receipts A-Timeline O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect
Projects
None yet
Development

No branches or pull requests

4 participants