Fetch return result unrelated to fetch command params. #334
Comments
|
Hey, as far as I know the only possibilities for two instances of IMAPClient to interact with each other are:
Skimming through the code related to the issue, it looks like the 2nd option. Maybe something else is altering the messages while you iterate over them? It's hard to tell anything more without seeing logs of what happens. |
|
Yes, something alterate the messages : the other imap client : thunderbird. The imapclient search for unflagged items : Then it try to get mail content of thoses mail Then it try to do something with those mail and then it marked those mail as flagged : That's a daemon so, it's always waiting through IDLE or through polling for new unflagged mail. When i launch this and modify flagged flag on thunderbird,
Which really seems related to thunderbird client action, but isn't what i'm expecting to see when i fetch "body.peek[]". |
|
I ran a small experiment and indeed the behavior is unexpected: import getpass
import sys
import imapclient
with imapclient.IMAPClient(host="bar.org") as client:
client.login("[email protected]", getpass.getpass())
client.select_folder("INBOX")
while True:
uids = client.search(['UNFLAGGED'])
for msgid, data in client.fetch(uids, ['INTERNALDATE']).items():
if b'FLAGS' in data:
print(msgid, data)
if b'INTERNALDATE' not in data:
print("PROBLEM FOUND")
if msgid not in uids:
print("msgid not in uids")
sys.exit()Running the script while flagging/unflagging random messages in the inbox results in: So indeed, we are receiving updates for messages we don't want (tested on |
|
Maybe unsolicited responses about other messages are getting mixed in? Debug logs so we can see the protocol level details would be very helpful. |
These logs show that message 28 is not in the FETCH query but still returned because it is received as an untagged response before the FETCH query. |
|
See this bug reported 18 years ago which describes well the problem we're seeing: https://bugzilla.mozilla.org/show_bug.cgi?id=55126 |
|
Unsolicited responses is actually a nice feature of IMAP, e.g. notifying users that new mail has arrived even whey they do not actively ask for it. Unfortunately, many email clients ignore these or even fail if they encounter these. One hacky way to avoid them is to call I would love to use ImapClient in my testing code but unsolicited responses would probably crash my test in unpredictable way, so cannot use it for now... . So if somebody added this, it would be appreciated. |
|
Thanks @christian-intreems a2net. It certainly is likely that unprocessed unsocilicted responses are getting incorrectly used as the response to some later command. I'll take a look at how we can solve this. |
|
Even worse, it seems imapclient/imapclient/response_parser.py Line 100 in 75bbce3 As a workaround, it is possible to execute NOOP before doing FETCH, but if another client is executing commands in the same folder on another connection, it is still possible that unsolicited responses will be returned. As a solution, FETCH response parser should drop non-FETCH results. As for unexpected FETCH results, it is impossible to filter them out: library user has to do it based on SEQ or UID and drop responses that it did not ask for. |
Hello, i'm using imapclient 1.1 (last stable, don't know when 2.0 will be released in pip) .
I discovered a weird bug when using :
sometime data return KeyError due to lack of b'BODY'. So i checked and i found a
dataobject related to what i'm doing with an other IMAP client at the same time (modify flags of messages).This behaviour is really weird. It should be either explained in doc or results should be correctly filtered to avoid this type of problem.
The text was updated successfully, but these errors were encountered: