Skip to content

Cannot restart search on new mail event #193

Closed
engram-design opened this Issue Apr 5, 2013 · 16 comments

2 participants

@engram-design

I'm wanting to simply listen for new mail coming through and process them, however it seems i'm getting some errors.

I've left out the error handling and connection settings for easy-viewing:

server.connect(function(err) {
    server.openBox('INBOX', false, function(err, box) {

        searchForNewEmail(); // initial search

        server.on('mail', function(items, err) {
            searchForNewEmail();
        });

        server.on('msgupdate', function(items, err) {
            searchForNewEmail();
        });
    });
});


function searchForNewEmail() {
    server.search(['UNSEEN'], function(err, results) {
        server.fetch(results, { headers: { parse: true }, body: true, cb: function(fetch) {
            fetch.on('message', function(message) {
                var body = '';

                message.on('data', function(chunk) { body += chunk.toString(); });
                message.on('end', function() { console.log(body); });
            });
        }}, function(err) {});
    });
}

When the 'mail' or 'msgupdate' event occurs, this error is thrown:

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error
    at CleartextStream.write [as _write] (tls.js:332:31)
    at doWrite (_stream_writable.js:211:10)
    at writeOrBuffer (_stream_writable.js:201:5)
    at CleartextStream.Writable.write (_stream_writable.js:172:11)
    at ImapConnection._send (C:\public_html\node_modules\imap\lib\imap.js:1575:22)
    at ImapConnection._send (C:\public_html\node_modules\imap\lib\imap.js:1566:19)
    at ImapConnection._search (C:\public_html\node_modules\imap\lib\imap.js:920:8)
    at ImapConnection.search (C:\public_html\node_modules\imap\lib\imap.js:912:8)
    at searchForNewEmail (C:\public_html\server.js:56:9)
    at ImapConnection.<anonymous> (C:\public_html\server.js:45:4)

Any ideas? Should I be calling logout() or disconnecting somewhere?

@mscdex
Owner
mscdex commented Apr 5, 2013

I am encountering this error as well, except in another situation. I posted an issue about it on node's issue tracker the other day.

@engram-design

Well, glad to hear its nothing I'm doing wrong! Thought it might have something to do with not releasing the streamReader that fetch uses or something. I'll keep an eye on that issue. Thanks for the reply!

@mscdex
Owner
mscdex commented Apr 7, 2013

Ok, for some reason it's not happening to me anymore with the master branch. Can you give it a whirl and test also?: npm install https://github.com/mscdex/node-imap/tarball/master

@engram-design

Indeed, the latest master helps - awesome! However, testing it a little (involving manually triggering msgupdate by unreading emails), it works just brilliantly when I set one email to 'unread'. It will also not misbehave when continuing to trigger events. But it'll throw an error when setting unread on more than one email, or when setting state in too quick of succession.

It may sound picky, but I'll be using this to monitor an inbox for incoming messages, which will likely have several emails being delivered at one time, which as of now, will throw some nasty errors!

assert.js:98
  throw new assert.AssertionError({
        ^
AssertionError: false == true
    at CleartextStream.ondata (C:\public_html\node_modules\imap\lib\imap.js:747:7)
    at CleartextStream.EventEmitter.emit (events.js:95:17)
    at CleartextStream.<anonymous> (_stream_readable.js:710:14)
    at CleartextStream.EventEmitter.emit (events.js:92:17)
    at emitReadable_ (_stream_readable.js:382:10)
    at _stream_readable.js:375:7
    at process._tickCallback (node.js:415:13)
@mscdex
Owner
mscdex commented Apr 7, 2013

Can you set debug: console.log in the object passed to the constructor and post the output to a gist?

@engram-design

Sure - to outline the steps, I successfully login to IMAP, with no new emails (I only care about UNSEEN emails). I mark one email as read, and it successfully processes it. I then mark two emails as unread at the same time, and produces the error. Hope you can wade through the debug info!

gist

@mscdex
Owner
mscdex commented Apr 7, 2013

@engram-design Can you please try the master branch again now?

@engram-design

Updated gist with latest master

@mscdex
Owner
mscdex commented Apr 7, 2013

@engram-design Ok try master again, I forgot to update the unsolicited check.

@engram-design

@mscdex that's certainly better and doesn't throw any errors, although it does keep happening if I push the updates up to ~10 at a time, or if marking another 10 emails unread while it's still processing the first 10...

@mscdex
Owner
mscdex commented Apr 8, 2013

@engram-design What keeps happening? The latest error or the previous or?

@engram-design

@mscdex Latest error. Updated gist to show slightly different debug output when marking 2 unread, and before they are finished being processed, marking another 2 as unread.

@mscdex
Owner
mscdex commented Apr 8, 2013

@engram-design Ah ok, give master branch another try again.

@engram-design

Okay, now it's just spewing out debug statements! Essentially

<== '* SEARCH 875 876 877 879 880 881 882\r\nA122 OK SEARCH completed.\r\n'

[parsing incoming] saw untagged SEARCH

<== 'A122 OK SEARCH completed.\r\n'

[parsing incoming] saw tagged response

==> A123 UID SEARCH UNSEEN


<== '* SEARCH 875 876 877 879 880 881 882\r\nA123 OK SEARCH completed.\r\n'

[parsing incoming] saw untagged SEARCH

<== 'A123 OK SEARCH completed.\r\n'

[parsing incoming] saw tagged response

==> A124 UID SEARCH UNSEEN


<== '* SEARCH 875 876 877 879 880 881 882\r\nA124 OK SEARCH completed.\r\n'

[parsing incoming] saw untagged SEARCH

<== 'A124 OK SEARCH completed.\r\n'

[parsing incoming] saw tagged response

==> A125 UID SEARCH UNSEEN


<== '* SEARCH 875 876 877 879 880 881 882\r\nA125 OK SEARCH completed.\r\n'

[parsing incoming] saw untagged SEARCH

<== 'A125 OK SEARCH completed.\r\n'

[parsing incoming] saw tagged response

==> A126 UID SEARCH UNSEEN

And from what I can tell, it gets stuck in a loop traversing the emails in the particular box...

@mscdex
Owner
mscdex commented Apr 8, 2013

@engram-design Ok, I was able to reproduce that locally this time and that should be fixed now.

@engram-design

@mscdex Yep, that seems to have fixed it for good this time! Thanks so much for addressing that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.