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

Read messages reappear as "new" after restarting the app. #24629

Closed
Tracked by #24392
Anagastes opened this issue Feb 23, 2023 · 21 comments · Fixed by matrix-org/matrix-js-sdk#3339
Closed
Tracked by #24392

Read messages reappear as "new" after restarting the app. #24629

Anagastes opened this issue Feb 23, 2023 · 21 comments · Fixed by matrix-org/matrix-js-sdk#3339
Assignees
Labels
A-Notifications O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@Anagastes
Copy link

Steps to reproduce

I have no idea how to force it. It suddenly shows up sporadically on the desktop clients.

It is using Arch Linux and the official package from there

Outcome

That read messages also keep the status.

Operating system

Arch Linux

Application version

Version von webgo: 1.11.23 Version von Olm: 3.2.12

How did you install the app?

https://archlinux.org/packages/community/x86_64/element-desktop/

Homeserver

Own Synapse on Debian 11, v1.77

Will you send logs?

Yes

@florianduros
Copy link
Member

florianduros commented Feb 27, 2023

Hi !

Is the unread bug is happening in rooms where threads are used ?

Maybe related in one of the issues of #24392

@florianduros florianduros added X-Needs-Info This issue is blocked awaiting information from the reporter S-Major Severely degrades major functionality or product features, with no satisfactory workaround O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience A-Notifications labels Feb 27, 2023
@Anagastes
Copy link
Author

Anagastes commented Feb 27, 2023

The Threats are not used there, but yes, I hadn't thought of that. Thanks.

The behavior seems indeed nevertheless related to the #24392.

Hi !

Is the unread bug is happening in rooms where threads are used ?

Maybe related in one of the issues of #24392

@florianduros florianduros removed the X-Needs-Info This issue is blocked awaiting information from the reporter label Feb 28, 2023
@jeffrson

This comment was marked as off-topic.

@t3chguy
Copy link
Member

t3chguy commented Mar 2, 2023

@jeffrson please use issue search. #20927

@jeffrson
Copy link

jeffrson commented Mar 2, 2023

Okay, sorry, I thought it might be related.

@davidmehren
Copy link

I can reproduce this with two different accounts, with Element Desktop Stable on Windows and Element Nightly both on Windows and Linux. I submitted two rageshakes, maybe they contain something useful.

@Anagastes
Copy link
Author

Anagastes commented Mar 21, 2023

Still present with Server v1.79 and

Element-Desktop
Version from webgo: 1.11.25
Version from Olm: 3.2.12

I have sent log data again.

@Anagastes
Copy link
Author

Still present with Server v1.79 and

Element-Desktop
Version from webgo: 1.11.26
Version from Olm: 3.2.12

I have sent log data again.

@Standard8
Copy link

I very frequently get this on the desktop client on startup but not always. A few rooms in particular seem to be stuck in this bad state.

Today, when I started it said I had 11 notifications from a one-to-one conversation (this was something I'd not seen before) but when I visited it, there was nothing since 9 days ago.

Clearing the cache & reloading doesn't help. In fact I just cleared the cache & reloaded, followed by restarting the app and 10 rooms are now showing as unread - and they haven't had any activity in that time.

Note that I use Element on both desktop & mobile, so that may or may not be related. I've submitted a couple of sets of logs.

@lanerussell
Copy link

Is this still an issue for you @Anagastes?
It's still present for me on:
Element-Desktop
Element version: 1.11.28
Olm version: 3.2.12

Synapse v1.80.0

Every time I open it, I must use "Clear cache and reload" to clear off the stuck notifications. Is there are issue tracker where we can follow progress on this? This is a critical problem that is causing a lot of confusion for those experiencing it.

@Anagastes
Copy link
Author

Anagastes commented Apr 11, 2023

Is this still an issue for you @Anagastes? It's still present for me on: Element-Desktop Element version: 1.11.28 Olm version: 3.2.12

Synapse v1.80.0

Every time I open it, I must use "Clear cache and reload" to clear off the stuck notifications. Is there are issue tracker where we can follow progress on this? This is a critical problem that is causing a lot of confusion for those experiencing it.

Yes, the error is still present with me.

Unfortunately, I don't know of any trackers. I only know that the error was listed here... but for reasons unknown to me is now in the archive -.-

https://github.com/vector-im/element-web/projects/27#card-88213606

@JeanPaulLucien

This comment was marked as off-topic.

@weeman1337 weeman1337 self-assigned this Apr 24, 2023
@weeman1337
Copy link
Contributor

Here is what I found so far: It works on initial sync. That corresponds to the title „Read messages reappear as "new" after restarting the app.“.

When storing the receipts we do handle receipts with thread_id = main and without a thread_id prop the same. Since it is an object we don't have a guaranteed order. If the „wrong“ one goes to cache there will be an unread message after restarting the app, when the cache is loaded.

@weeman1337
Copy link
Contributor

weeman1337 commented Apr 24, 2023

image

@clokep
Copy link

clokep commented Apr 24, 2023

We should send a /receipt for the main „thread“ when viewing the main timeline?

Yes, the main timeline is "just" another thread.

How should we proceed if we got both, main and unthreaded receipts?

The unthreaded receipt applies to an unthreaded view of the room (so essentially across all threads). For each thread you need to compare the unthreaded receipt and the receipt for that thread and use the one which is "later".

What unthreaded receipt should we send when viewing a room?

Element Web is a threaded client and should never send an unthreaded receipt (unless you want to mark a room as fully read, in which case an unthreaded receipt on the latest event in the room, regardless of thread, should be sent).

@weeman1337
Copy link
Contributor

weeman1337 commented Apr 25, 2023

My suggestion:

We should store receipts for the main thread separately here. It should be persisted then as well. When reading the persisted data it should automagically be restored here.

This will fix the issue after a new complete sync.

Currently we do sometimes overwrite main thread or unthreaded receipts with each other here. Since we then lose the receipt information it may be necessary to trigger an entire sync for a fix.

@andybalaam
Copy link
Contributor

/me is desperate to factor out the receipt part from accumulateJoinState and write some unit tests

@weeman1337 weeman1337 removed their assignment Apr 26, 2023
@andybalaam andybalaam self-assigned this Apr 26, 2023
@andybalaam
Copy link
Contributor

First step: refactor the receipt code out of the sync accumulator so we can test it in isolation.

@Anagastes
Copy link
Author

Anagastes commented Jun 9, 2023

@andybalaam

Is it known when the fix will be released? I can't find #24629 and #24392 in the release notes yet.

Sorry to follow up, it's just regrettably extremely annoying in general operation.

And also in v1.11.33 the error is still present :S

@andybalaam
Copy link
Contributor

Hi @Anagastes, I'm sorry it's still happening! It's still happening to me too and annoying me too.

The last fix that might still be trickling towards you is matrix-org/matrix-js-sdk#3427 . That should be in v1.11.34.

If that one doesn't prevent your problem, please log a new bug.

If you want to find out early, please try https://develop.element.io or the Nightly builds.

Thanks for your patience. We've fixed lots of issues in this area, but every time we turn over another rock we find 10 more, so it's frustratingly slow to show results.

@Anagastes
Copy link
Author

Hi @Anagastes, I'm sorry it's still happening! It's still happening to me too and annoying me too.

The last fix that might still be trickling towards you is matrix-org/matrix-js-sdk#3427 . That should be in v1.11.34.

If that one doesn't prevent your problem, please log a new bug.

If you want to find out early, please try https://develop.element.io or the Nightly builds.

Thanks for your patience. We've fixed lots of issues in this area, but every time we turn over another rock we find 10 more, so it's frustratingly slow to show results.

Sorry to breathe life back into this issue, but even with the stable 1.11.34 it is not fixed for me.

su-ex added a commit to SchildiChat/matrix-js-sdk that referenced this issue Dec 13, 2023
* Ensure we do not add relations to the wrong timeline ([\matrix-org#3427](matrix-org#3427)). Fixes element-hq/element-web#25450 and element-hq/element-web#25494.
* Deprecate `QrCodeEvent`, `SasEvent` and `VerificationEvent` ([\matrix-org#3386](matrix-org#3386)).
* Move crypto classes into a separate namespace ([\matrix-org#3385](matrix-org#3385)).
* Mention deno support in the README ([\matrix-org#3417](matrix-org#3417)). Contributed by @sigmaSd.
* Mark room version 10 as safe ([\matrix-org#3425](matrix-org#3425)).
* Prioritise entirely supported flows for UIA ([\matrix-org#3402](matrix-org#3402)).
* Add methods to terminate idb worker ([\matrix-org#3362](matrix-org#3362)).
* Total summary count ([\matrix-org#3351](matrix-org#3351)). Contributed by @toger5.
* Audio concealment ([\matrix-org#3349](matrix-org#3349)). Contributed by @toger5.
* Correctly accumulate sync summaries. ([\matrix-org#3366](matrix-org#3366)). Fixes element-hq/element-web#23345.
* Keep measuring a call feed's volume after a stream replacement ([\matrix-org#3361](matrix-org#3361)). Fixes element-hq/element-call#1051.
* Element-R: Avoid uploading a new fallback key at every `/sync` ([\matrix-org#3338](matrix-org#3338)). Fixes element-hq/element-web#25215.
* Accumulate receipts for the main thread and unthreaded separately ([\matrix-org#3339](matrix-org#3339)). Fixes element-hq/element-web#24629.
* Remove spec non-compliant extended glob format ([\matrix-org#3423](matrix-org#3423)). Fixes element-hq/element-web#25474.
* Fix bug where original event was inserted into timeline instead of the edit event ([\matrix-org#3398](matrix-org#3398)). Contributed by @andybalaam.
* Only add a local receipt if it's after an existing receipt ([\matrix-org#3399](matrix-org#3399)). Contributed by @andybalaam.
* Attempt a potential workaround for stuck notifs ([\matrix-org#3384](matrix-org#3384)). Fixes element-hq/element-web#25406. Contributed by @andybalaam.
* Fix verification bug with `pendingEventOrdering: "chronological"` ([\matrix-org#3382](matrix-org#3382)).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Notifications O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect
Projects
None yet
Development

Successfully merging a pull request may close this issue.