For #6098

If there is a more comprehensive way to test this it would be great, but this covers the known cases in ServerResultUtils currently

Thanks @bbarkley this is helpful.

Basically the issue is that we need some way to know when the request is finished. Previously we recommended using onDoneEnumerating to know when the body was completely sent to the client. This does not work, however, if any exceptions happen before the body is sent out.

This is especially problematic if the exception happens in the Netty server (this code), since then your application can not be made aware of the error.

So the solution is one of the following:

1. Always run out the Enumerator/Source so any callbacks are executed.
2. Provide an alternative hook for when the request is finished.

Given that a range of errors might occur that could prevent us from running out the enumerator, I'm thinking option 2 might be the better solution.

Well option 2 was what we had back in 2.2 with GlobalSettings.onRequestCompletion - I'm not sure why that was removed, but the suggested replacement was to use onDoneEnumerating. The problem is that onRequestCompletion didn't have access to the result - if it was passed the request and result (which may be the 500 Play is returning) that would be great.

This PR is 8 months old and against 2.4.x -- unless it's going to be rebased against 2.6.x (assuming that's even an option) I suggest we close it

@gmethvin
Sorry to revive a dead thread, but what is the recommended way now to ensure that a callback gets fired from a possible empty enumerator of a Result?

After upgrading from play 2.4.6 to 2.4.8 I've seen a regression for this behavior with the changes in place from #6098. I'm trying to run the content through an enumeratee and fallback in the cases where there is no input (NoContent or Accepted) but now the onDoneEnumerating is never called for those types of Results.

Quick update, this only happens for NoContent. It works for Accepted even without passing it a content argument

@mjrussell Caught this when checking old issues. :) It should be fixed in #7004

Thanks @FranklinYinanDing !