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

parse error in noop loop from "seen" event from server #128

Open
norcalli opened this issue Jul 29, 2019 · 4 comments
Open

parse error in noop loop from "seen" event from server #128

norcalli opened this issue Jul 29, 2019 · 4 comments

Comments

@norcalli
Copy link

norcalli commented Jul 29, 2019

Pretty easy to reproduce:

    let mailbox = imap_session.examine("[Gmail]/All Mail")?;
    loop {
        println!("tick");
        if let Ok(response) = imap_session.unsolicited_responses.try_recv() {
            println!("response: {:?}", response);
            match response {
                UnsolicitedResponse::Recent(id) | UnsolicitedResponse::Exists(id) => {
                    print_email(&mut imap_session, id)?;
                }
                other => {
                    println!("Other {:?}", other);
                }
            }
        }
        std::thread::sleep(std::time::Duration::from_secs(1));
        imap_session.noop()?;
    }

While in this loop, read an email and notice that the process exits with the following error:

Error: Imap(Parse(Unexpected("Fetch(31724, [Uid(85608), Flags([\"\\\\Seen\"])])")))

It seems like this is a bug in not adding it to the unsolicited events. This is with a Gmail server.

@jonhoo
Copy link
Owner

jonhoo commented Jul 30, 2019

Ah, interesting. I believe this is fixed by #114 by @Emm54321, specifically the changes to handle_unilateral around here. That adds a part that handles fetch replies as unilateral responses, which I believe should fix your issue. That PR isn't too far from landing I think, though if you are in a rush to get this fixed, you could just lift the changes related to unsolicited responses from that PR and file it as a separate PR :)

@norcalli
Copy link
Author

I'm also interested in the results of that PR since that is the smarter alternative to a noop loop when the server has IDLE. I believe that if I did take that part of the PR out, then I could use IDLE and still iterate over the unsolicited responses after IDLE ends, right? In that case, then I think that the iterator is merely a nice facade over a loop + IDLE + try_recv(). I'll try to implement that PR, then.

@jonhoo
Copy link
Owner

jonhoo commented Jul 31, 2019

Yes indeed!

@norcalli
Copy link
Author

norcalli commented Aug 4, 2019

PR up. Testing locally looks good so far.

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