Anyone that can help on the code coverage issue?

I found a workaround for the missing close event and added an extra test that attempts to provoke a file descriptor leak by aborting the response.

The only missing component to this patch is the code coverage. The best idea I have for this (besides a complicated mocking setup), is to collate the fstat error with the open error by using something like async.series(). Would this be acceptable?

This is how we mock file system errors: https://github.com/hapijs/subtext/blob/master/test/index.js#L883-L897

I will have a go at another test using mocking.

@hueniverse Any thoughts on the close hook? Is hapijs/hapi#2110 a possibility or can it be handled using promises in 8.0?

Done.

@kanongil how do you feel about taking over as lead maintainer of this module?

@hueniverse Thanks for the offer. It sounds like an interesting challenge, and I guess it would help you concentrate your efforts on the core of the project. What kind of commitment would you expect from me?

@hueniverse I guess this patch will have to wait a bit, as I am unable to install a suitable hapi@8.x to test against.

This module is pretty low maintenance. You are the first in a long time to open issues against the file/directory handlers, and you seem eager to do the work so it isn't much more than getting to make the call about which changes go it, with someone else from the hapi core team doing a code review before merging. My guess is that it will stay a pretty low key module.

As for 8.0, you can manually link to the -rc1 modules in the shrinkwrap file, or give it a day and an 8.0-rc1 will be published.

@hueniverse I'm in. Where do I sign up? Do you need something else from me?

@kanongil you are now the lead maintainer and all setup on npm and github.

The patch is no longer WIP, and I would like it to be merged at some point. Any comments on the latest implementation?

My main concern is that the open file descriptors can get "lost" and never get closed. Assuming that hapi remembers to call close, this should only ever happen if a request is never reply()'ed to by a hook between the prepare and marshal phases. I'm inclined to think that this is mainly a theoretical concern but I'm open to feedback regarding this.

Note that with this change, we now open fd for no reason when using pre-compressed files. I am not too concerned about it as the issue this fixes is more important but it does increase the number of fd created when errors are involved.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.