meli gets stuck on `set seen' for mail (threads) at random #98
Labels
No Label
IMAP
JMAP
Maildir
Retired
User Experience
User Interface
bsd
bug
contacts
currently worked on
documentation
duplicate
easy
enhancement
help wanted
invalid
linux-gnu
macos
mbox
notmuch
question
security
wishlist
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: meli/meli#98
Loadingโฆ
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
There's one mail thread, which I can't `set seen' so this folder's box can't
reduce the counter because of that. I think, if I restart meli and go straight
to this folder and set seen for these emails, then it will get read, but not
doing it right away, it gets stuck, even going inside thread and trying read
each email, it doesn't work.
When this happens, after I execute `set seen', meli gets two colored lines at
the bottom of screen, orange and red, and it's stuck there for quite long time
then it simply goes away.
I've noticed that sometimes when that happens, if I have meli closed much later,
when opening it again, the emails have been already `set seen' and the folder counter is zeroed.
So it seems that
meli was in some broken state formerly where it didn't update to the real state
of the mails / folder.
#imap
I've pushed some microfixes these past few days, which could cause this behavior. I'll keep a lookout if this happens to me from now on, and if you confirm it as well we can consider it fixed for now.
Read state has been quite flaky for me. Sometimes the folder mail counter is zero while there's still unread emails, sometimes I set seen and they don't update state, sometimes the email is shown as read but then the counter doesn't update, etc.
Often I'm seeing mail counters act strangely. One thing that often happens is just after opening meli it simply won't update/display any folder mail counters, but when I browse the folders, they have unread emails. Another thing is that sometimes some folder counter will suddenly display a count of all the emails in the folder instead of just unread ones.
Does the server support
LIST-STATUS/CONDSTORE? Does deleting the header cache do any difference?@epilys I'm using gmail accounts and dovecot imap server, this happens in both cases. How to check for
LIST-STATUS/CONDSTORE? I don't see any error intrace.logregarding that, all I see isM3 OK Success,"M3 OK Enabled", etc aftersent: M3 ENABLE CONDSTORE.On header cache, I'm gonna delete it and see how it behaves in the following hours/days.
Right after deleting cache and restarting meli, it didn't update folder mail counters, even though it was listing new emails. After restarting meli it updated the counters.
I will play around with an IMAP account and see if I can get it reproduced and report back. ๐
Confirming that I'm still getting mail count jump from unread to all-mails. Seems to happen after new mails arrive. Restarting fix the counter.
Sorry, closed issue by accident.
Pushed some commits that try to fix the counting logic, since it's been a while I will close this issue and we can re-open it if it's still there
Reopening since it was mentioned on IRC that this still keeps happening.
It seems to me that in set_flags(), when
STORE FLAGSis succesful, we can return the refresh events from there immediately instead of relying on getting the update from the server.However, that'd mask the real problem: not getting updates on flag change events (or possible all events). Do you get refresh updates when changing flags or getting new mail or removing mail from other clients? If not, does it happen after at most 3 minutes?
I used aerc for quite a while and hardly hit this. Can't remember the mutt experience as it was too long ago. FWIW, nothing changed on meli regarding this, don't you experience it at all? I use meli daily but at the moment I don't expect it to obey me, it doesn't matter which account type, gmail or not, it often don't get these counters right, and also often I set seen multiple times for an email but it gets stuck as unread in the UI.
Ah, yeah, I use K9 on LineageOS and have zero problems.
EDIT: I think you misunderstood my question, I meant that if you make changes from other clients, do they show up on meli?
I haven't had it happen to me (set sth seen and never get any feedback on it) and I've been testing regularly with 3 different mail servers including Gmail. Which is why this is puzzling for me.
Some thought I just had: is the counter in the status bar on the bottom updated or is it just the counter in the menu?
If it's just the counter on the sidebar, could you see if commit
7efbe6d692solves this?Yes. I just closed and opened meli, then read some unread emails on my cellphone, and after a while it was updated on meli (counter/mail). I'm not confident with the test though because it was in ideal conditions just after a couple of minutes opening meli, my experience has shown in general that things are not that pretty after it has opened for an hour or so, will have to confirm.
I will check. Notice though that I also mention stuck unread emails, not just the counters (yep I'm only talking about menu counters so far, I completely missed status bar info).
There's something funky happening now, maybe associated with synching to a cache read. I just built meli, then started it, and all folder counters were fine. Then, I switched to the folder where I've read two emails from my cellphone earlier. Guess what? When I switched to this folder the mail counter jumped by 2, and there was 7 unread emails, both in the counter as in the mail list, but I had read two of those already, and meli even got that, before I opened the folder.
And calling
set seenon those is further increasing the counter by 1 after last commit.At the moment I'm not seeing the all mails counter jump happening anymore, but only that has gone away.
Alright, I will keep looking again and again at the code (not just the imap, but UI too). If you are not fatigued yet you could keep up with master and test if anything changes. Thanks a lot and I'm sorry I haven't figured this out any sooner.
I think this is more easily reproducible when you, start with a fresh and consistent cache (make all emails read, close meli, wipe out all header cache dbs, open meli, wait it finish fetching headers, close meli, open it again), then have a new unread email arrive in any unfocused folder (wait meli display there's unread email), then open and mark this email as read from another client (I did it from K-9 on mobile), then go to meli still open, the mail won't be marked as read until restarting. This e-mail has been set as read already, but is unread on meli, focusing the folder of this e-mail (with counter of 1 or 0 depending on the delay), there's an unread e-mail, hover it and set it as seen, it won't do it, it is stuck as unread, even if the folder counter is 0, inside it will be an unread e-mail. This just happened to me, while I was able to mark as read e-mails I had not already marked as read from outside, the one I had marked as read on my mobile client got stuck as unread on this meli session, restarting meli brought it back to consistent state, no unread e-mails, but, this often doesn't happen and I get a few e-mails which are forever stuck in unread state, and which cause folder counters to jump suddenly when focusing/unfocusing bad folders. Only fix is header cache wipe out, but it doesn't take long to get back to square one.
This test was on my own mail server (postfix/dovecot, no gmail involved).
Thanks so much for the detailed steps! I will really really try to reproduce it asap.
Noting this down so I don't forget: this might also be caused by emails having different UIDs on an IMAP server but the same message-id and thus meli ignores the duplicate message-id copies, which can remain unseen since they will never show up in the list. They can show up when querying the server for the mailbox totals, though.
@oblitum can you check out if the counters are accurate if you switch to
plainmode? (set plaincommand) I just found out a folder that reported 16 unread messages but without any unread messages had those missing ones in plain mode. It's a threading bug.I just tried this, often when I mark an email in a folder as read, the counter can: drop as expected, increase, or not change. This time I've marked an email as read and the counter didn't change, the folder just had one single unread email, I've set it as read, it was no more highlighted as unread, but counter kept stuck as 1. I've then switched to plain mode afterwards, and back, and forth, it made no difference. I know the way for it to correct itself is to close and open meli, then it'll get cleared.
With time I'm somewhat learning how some aspects of this problem works. For example, one thing I'm starting to trust is that, with my medium-sized mail box, which contains 60 folders (I use a lot of those for tagged emails), if I open meli and go right away about checking emails and marking as read, etc, things go downhill, the counters don't behave well, etc. If I open meli and let it there for a while (probably for some initial background processing), and only then go about interacting with it and marking emails as read, then the counters works (to some extent, often they get back at stopping working at random).
Also, I'd like to comment that these sync issues aren't bound solely to counters. I'm nearly always facing issues when attempting to delete emails. For example, I just got one email I wanted delete, so I deleted it with
:delete, it didn't go away. I closed and open meli, it was still there, then I:deleted again, and it didn't go away, then I closed and open meli, and it was gone already. Crashing didn't happen this time but it often does when attempting to delete an email.The whole design is fundamentally flawed it seems. Maybe I will retry a partial or complete rewrite of mail events and handling from scratch. I know it's not as serious as not being able to send or read email but this is still a big usability problem. I want to solve this before the next version, alpha or not.
I agree that it appears quite tricky to patch as-is.
I haven't been seeing this bug lately; closing it as probably fixed/stale and reopen it if it happens again.