This Gist serve as an illustration for a Stack Overflow thread. It contains a real situation, where a Bluebird promise needs to receive its handler asynchronously.
The goal is to launch a long process, which writes a preview to stdout upon startup. The launchProcess()
function should launch the process and return once the preview has been read. In particular, it should not wait for the completion of the process.
As an example, you would could think to a large file download (written to the disk), with the HTTP headers written to stdout as soon as they are received.
launchProcess.js
: the initial and intuitive implementation, which triggers a Bluebird warning about a possible unhandled rejection (false positive).launchProcess_workaround.js
: the same as above, but with a workaround to avoid the false positive. Although more compact, this is also less intuitive in my opinion.client.js
: a possible quick & dirty client to illustrate howlaunchProcess()
could be called.
@benjamingr: No, that seems to be intentional.
launchProcess()
may fulfill withcompletion
being rejected later, that's fine.The problem I see is rather when
completion
fails beforestartup
settles, becuase in that case we indeed do have an uncaught rejection. It should be possible to rejectlaunchProcess()
sooner if that happens (like theworkaround.js
does it explicitly).The
process
api is not easy to consume indeed :-) It would be necessary for all the consumption of the stream to fail when the process fails, I don't think there is currently anything that ensures that.