Possible bug in reply and stream handling

[nover]

The issue

We, my team and I, encountered something strange today with regards to replying with streams.

The use-case is as follows:
We are building an API with hapi, and some of the handlers will have to take an incoming request, enrich it, call a backend service and then pipe that backend server response back to the caller.

We are using the request module to perform the call which in turn can create a http.IncomingMessage on the resp.on('response')' event.

The issue is, if we call reply with the response stream directly, it works as expected. However, if the code is performing some async things first and then returning the response stream in the promise resolve, reply does not work as expected, nor when using a callback approach.

Reproducing the issue

I have created a repository with the most bare-bones code to reproduce the issue:
https://github.com/nover/node-hapi-reply-funky

Basically it's a small hapi API with 3 routes:

• /promise/ which does something async and then once the response stream is ready it returns it
• /immediate/ which uses setImmediate to simulate something async the response stream as a result
• /reply/ which is basically just calling reply once we have the response stream

What really gets me is that in all 3 cases the http headers from the backend service will be returned,
but only for the /reply/ route do we get the full body.

The associated test suite demonstrates the problem.

Context

Tested on

• node version: 6.9.2 and 6.9.4
• hapi version: 16.1.0
• os: macOS Sierra 10.12.2

[nlf]

this isn't because of hapi, but rather how streams work (particularly how streams are handled in request). there are several open issues relevant to this issue.

the tl;dr is call stream.pause() before your async code, otherwise your stream is being consumed before hapi receives it. that's why your responses are missing data. that also explains why your handler that lacks an async function works just fine.

[nover]

@nlf Thanks for the quick response and you are indeed correct, calling stream.pause() fixes the issue.

I guess you can go ahead and close the issue then. I'll update my test repo with the fix in case anyone stumbles upon it.

[nlf]

glad i could help 👍

streams are still kind of an awkward thing to deal with, especially with all the different "versions" of them that are out there