Just a hypothesis:

Could it be that the instantiation of the Socket triggers an `onReady` callback (which is bound to `_flush`), yet before onReady fires, we're already sending data which in turn also calls `flush`, and does it all synchronously, so we now ended up calling flush before onReady ever fired. In other words: zmq is not yet ready to receive requests?

A process.nextTick might still be too fast, and so our _flush call (through send()) is still called before onReady fired.

Changing that to setTimeout slows it down enough that onReady will likely have fired, and all is well in libzmq.

I don't actually know when the onReady call fires, so I may be way off. But if it's correct, then we could delay the libzmq interaction inside of _flush until onReady has fired through a simple flag and do away with the outer async wrapper (be it setTimeout or nextTick).