Open iby opened 5 years ago
The argument passed to 'close'
event handlers is merely what's passed from node core and is more of a historical thing.
I'm not sure I understand the problem though, you should always handle unexpected errors. Why are you concerned about having to removing the event handlers?
I'm not very familiar with the underlying api and what supposed to be happening, but pretty sure it shouldn't end with an error in this case. At the same time I do want to know of any errors, but you are right, this is more of an ideological case than practical.
I'm using this in a cli app and wrapping the module calls into promises to make use of the async
and await
. For some reason the code fails when the error callback fires and rejects the already resolved promise. From what I understand, failing the already resolved promise shouldn't affect it, but it somehow causes the cli app to fail. And without closing the stream the app never finishes.
I ended up handling those cases on per-promise basis, which seems to work smoothly so far, but it's a lot of boilerplate for what should work out of the box. From what you're saying I understand it's not the project related issue? Should it be reported else where?
If the issue is only present with Promises, then that's outside the scope of this project.
The messed up promise is the consequence, not the cause. The problem is with the imap package (or a dependency) randomly sending an error
event after the close
event when end()
ing it.
The isolated code above illustrates this. Like said, this doesn't happen all the time, but often and consistently with different services.
Not sure if it is connected, but I have a software running against two email service providers. Calling imap.end() triggers "end" and "close" events if connected to server #1, but only "close" event in case of server #2. Only difference is username, password and email server name.
I'm trying to close a no longer needed connection, and sometimes this leads to different socket errors.
Stack
``` anonymous(), MailboxUtilityTest.ts:32 onceWrapper(), events.js:291 emit(), events.js:203 _onError(), Connection.js:151 emit(), events.js:203 TLSSocket._emitTLSError(), _tls_wrap.js:748 onerror(), _tls_wrap.js:330 Async call from TLSWRAP init(), inspector_async_hook.js:21 emitInitNative(), async_hooks.js:134 TLSSocket._wrapHandle(), _tls_wrap.js:514 TLSSocket(), _tls_wrap.js:412 connect(), _tls_wrap.js:1405 anonymous(), Connection.js:1708 Object.Stack
``` anonymous(), MailboxUtilityTest.ts:32 onceWrapper(), events.js:291 emit(), events.js:203 _onError(), Connection.js:151 emit(), events.js:203 emitErrorNT(), destroy.js:91 emitErrorAndCloseNT(), destroy.js:59 processTicksAndRejections(), task_queues.js:77 Async call from TickObject init(), inspector_async_hook.js:21 emitInitNative(), async_hooks.js:134 emitInitScript(), async_hooks.js:341 TickObject(), task_queues.js:102 nextTick(), task_queues.js:130 anonymous(), destroy.js:43 Socket._destroy(), net.js:595 destroy(), destroy.js:37 onStreamRead(), stream_base_commons.js:183 Async call from TLSWRAP init(), inspector_async_hook.js:21 emitInitNative(), async_hooks.js:134 TLSSocket._wrapHandle(), _tls_wrap.js:514 TLSSocket(), _tls_wrap.js:412 connect(), _tls_wrap.js:1405 anonymous(), Connection.js:1708 Object.It's a pain to manage those locally, since the failures are inconsistent and close handler comes through with
failed: false
as if there's no error.One way to manage these is to use a complex once-like pattern, which would install and remove listeners. Otherwise, by simply removing all error listeners prior calling end, which doesn't feel like the right thing to do.