search

bamthomas / aioimaplib

Python asyncio IMAP4rev1 client library
GNU General Public License v3.0
138 stars 59 forks source link

Not all commands use a timeout or can be cancelled #58

Open jgosmann opened 3 years ago

jgosmann commented 3 years ago

It seems that not all commands are consistently using the configured timeout, in particular I noticed that for UID only the UID FETCH command gets passed the timeout. Is there a reason for this? (I'm not super familiar with IMAP.)

As a workaround I apply await asyncio.wait_for(..., timeout) manually around the corresponding invocations. However, I noticed that this seems to fail to properly cancel the task. At least in the end I'm left with warnings like this one if timeout occur:

Task was destroyed but it is pending!
task: <Task pending coro=<Command.wait() done, defined at /Users/jgosmann/Library/Caches/pypoetry/virtualenvs/dmarc-metrics-exporter-n4MZO14v-py3.7/lib/python3.7/site-packages/aioimaplib/aioimaplib.py:209> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x103fbb510>()]>>
bamthomas commented 3 years ago

That's a very good question. I just found the comment for the commit 8766c77cd6e407e6fe8b33add4e8acd6490dde7c :

the timeout had been set at the command level for fetch because it can be long, thus the global API timeout was expiring. It is the same for uid fetch and append.

So I guess that it has been added just because the global timeout was expiring in our server. Your workaround is looking fine. I think that the warning would be the same if the timeout would be set at the command level as there still would be a pending task cancelled.