Tck: Tests for error handlers with flux controller methods

[jeremyg484]

After investigating micronaut-projects/micronaut-reactor#238, I've got some questions to improve my understanding of how @Error handlers work in conjunction with @Controller methods that return a Flux, and try to figure out if there are any actual issues we need to address.

The test added by this PR exercises the existing behavior in various combinations of a Flux returning controller method in conjunction with an @Error handler method. It demonstrates the following:

A) A Flux returning controller method that is annotated with @SingleResult results in the @Error handler getting invoked as expected if the Flux signals an error - i.e., return Flux.error(new MyException())

B) A Flux returning controller method that throws an exception results in the @Error handler getting invoked regardless of whether or not the method is annotated with @SingleResult.

C) A Flux returning controller method that is not annotated with @SingleResult results in the @Error handler not getting invoked if the Flux signals an error as in scenario A.

D) A Flux returning controller method that is not annotated with @SingleResult that has an error signaled after the body has already begun to be written in the chunked response causes the connection to be closed and a warning logged without invoking the @Error handler as expected.

My questions:

1. I would guess that the behavior of scenario C is intentional because it is a chunked response and it is possible that the headers have already been written. Is that guess correct?

2. If so, would it be possible for us to treat a Flux that immediately signals an error (without any data events) differently? Could we invoke the error handler at that point, or is it too difficult because status and headers have already been written? 

3. Is the behavior in the B scenario also intentional? It seems inconsistent to me that throwing an exception results in different behavior than signaling an error.

[sdelamo]

@jeremyg484 did you forget to push the code?

[jeremyg484]

@jeremyg484 did you forget to push the code?

@sdelamo Fixed.

[sdelamo]

The current assertions describe the current behavior, do they match your expected behavior? If not write comments in the test describing why they are not behaving as expected.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[jeremyg484]

In separate discussion with @yawkat, it was confirmed that my assumptions in questions (1) and (3) are correct and the existing behavior is as intended. Re: question (2), he also confirmed that it might be possible, but difficult, to change the implementation such that the error handler still gets invoked in the chunked response case if the error is signaled immediately before any data.

I think it would be good to do this if we can, as it would be more consistent with the behavior of immediately thrown exceptions and less surprising to the user. @sdelamo I have added a comment to the testErrorHandlerWithFluxChunkedSignaledImmediateError method to point out this desired change. I will investigate the implementation further to see how it might be done.

The test has also been updated to have the error handler produce a more unusual status code (418) to better ensure the assertions are correctly identifying that the handler was invoked.