~migadu/alps#122: 
Investigate more robust solution to ghost messages

This is likely related to some kind of Dovecot bug.

If, while alps has an open IMAP connection, another client marks a message as \Deleted and then EXPUNGES it, alps will still receive the message on the next FETCH (and STATUS, interestingly), with the \Deleted flag set and the envelope missing. I've written aaa30ead41532fa920f3c5e0298ed52196d7fe3a which prevents the template from crashing in this situation, but at some point we should do a deeper investigation on the problem.

Status
RESOLVED FIXED
Submitter
~sircmpwn
Assigned to
No-one
Submitted
4 years ago
Updated
4 years ago
Labels
mvp

~migadu 4 years ago

This does not occur on Rainloop which uses the same IMAP server in our context. I have a feeling some caching happens inside of our code.

~sircmpwn 4 years ago

Does Rainloop keep the IMAP connection open between requests?

~migadu 4 years ago

PHP cannot do that asfik.

~sircmpwn 4 years ago

Yeah, that's an important part of the reproduction steps. I've already isolated the problem to the IMAP server. It seems like Dovecot has had similar issues before.

~migadu 4 years ago

If we receive the message with the \Deleted flag, we should simply skip it and not show it, which would solve it?

~sircmpwn 4 years ago

We could do that, but it would be a workaround - wouldn't it be better to investigate and determine the root cause?

~sircmpwn REPORTED FIXED 4 years ago

I put in a workaround. Closing this ticket as any issues with IMAP wouldn't be alps bugs.

Register here or Log in to comment, or comment via email.