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

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

Open
jgosmann opened this issue Dec 30, 2020 · 1 comment
Open

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

jgosmann opened this issue Dec 30, 2020 · 1 comment

Comments

@jgosmann
Copy link

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
Copy link
Owner

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

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.

jgosmann added a commit to jgosmann/dmarc-metrics-exporter that referenced this issue Dec 30, 2020
This will reconnect on every polling cycle as this was easier to
implement than only reconnecting on a lost connection. However, for my
use case there is only a low volume of incoming messages, so that it
makes sense to have a long polling interval in which case individual
connections to poll might be even better than a persistent connection.

Due to limitations in the aioimaplib [1], a timeout in one of the
commands will leave a cancelled, but pending task around. This also,
produces warnings in the tests that cannot be silenced.

[1]: bamthomas/aioimaplib#58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants