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

Wrongful IDLE timeout reset on response #300

Open
gin-ahirsch opened this issue Jan 24, 2025 · 0 comments · May be fixed by #303
Open

Wrongful IDLE timeout reset on response #300

gin-ahirsch opened this issue Jan 24, 2025 · 0 comments · May be fixed by #303

Comments

@gin-ahirsch
Copy link

gin-ahirsch commented Jan 24, 2025

I'm connecting to an IMAP server that boots IDLE connections after 30 minutes. I'm using imap-3.0.0-alpha.14, pretty much straight forward

    let imap = client.login(username, password)?;
    let mbox = imap.select(inbox)?;
    imap.idle().wait_while(|response| { ... });

I works well, apart from getting booted periodically.

I believe the issue may be, that the time is not counted from the start of the IDLE loop, but for every read, since the timeout is implemented by calling TcpStream::set_read_timeout() once before the loop. So when a response arrives on the client, the timeout is effectively reset.

z33ky added a commit to z33ky/rust-imap that referenced this issue Jan 28, 2025
The code used to apply the set timeout value to the TcpStream before
entering the IDLE loop. This effectively resets the timeout after
receiving and handling incoming messages, which nullifies the purpose of
the timeout when messages are received.

This change remembers when the IDLE command is sent initially and uses
that value to set the remaining time for the TcpStream timeout. This
allows the IDLE loop to reconnect the IDLE connection at the appropriate
time.

Fixes jonhoo#300.
@z33ky z33ky linked a pull request Jan 28, 2025 that will close this issue
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

Successfully merging a pull request may close this issue.

1 participant