http-netty: let RetryingHttpRequesterFilter return responses on failure

[bryce-anderson]

Motivation:

Sometimes people just want to get the last failed response when the retry
loop ends. However, right now we only yield the exceptions that where
created. Users can't do this smuggling themselves in a generic way via the
HttpResponseException because it could lead to resource leaks.

Modifications:

Let users simply return the last failed response when the retry loop
exits unsuccessfully.

[bryce-anderson]

I'm certain this can have a better name and clearly it needs docs before merging. Name suggestions welcome.

[bryce-anderson]

I also think this API is a bit awkward: first you must turn a response into an HttpResponseException and then it's going to be discarded. Alternatively, we could just have a different lambda to the tune of Function<Boolean, HttpResponseMetadata> shouldRetry.

[idelpivnitskiy]

Right now we don't have RS operators to achieve retries without mapping into exceptions. If we go the route of clean retry of response meta-data without mapping to exceptions, it's possible but will take longer.

Current rational was that some users want to always map responses to exceptions, that's why we have independent responseMapper. Then some users may want to retry that, so there is a 2nd method for them to retryResponses. We decided to put them next to each other on the same builder instead of offering 2 different filters bcz they often used together.

I agree that having a 3rd method that works only if the other 2 also configured is not intuitive. Alternatively, we can consider adding a retryResponses overload that takes a boolean to make a decision if it need to unwrap the original response or not.

[daschl]

I like the idea of the boolean overload, which would signal that it needs to be configured "together". Alternatively when building, we should at least check if this value is set to true and others are in their default state to reject the config?

[bryce-anderson]

A risk of this PR is that it's very difficult to know for sure that the deferred response is properly drained since it gets smuggled through the error channel.

[idelpivnitskiy]

Right now we don't have RS operators to achieve retries without mapping into exceptions. If we go the route of clean retry of response meta-data without mapping to exceptions, it's possible but will take longer.

Current rational was that some users want to always map responses to exceptions, that's why we have independent responseMapper. Then some users may want to retry that, so there is a 2nd method for them to retryResponses. We decided to put them next to each other on the same builder instead of offering 2 different filters bcz they often used together.

I agree that having a 3rd method that works only if the other 2 also configured is not intuitive. Alternatively, we can consider adding a retryResponses overload that takes a boolean to make a decision if it need to unwrap the original response or not.

[bryce-anderson]

@idelpivnitskiy, with the additional constraint of not returning the body this got dramatically simpler but I'm not certain having an empty response body is what we wanted.

[daschl]

I like the idea of the boolean overload, which would signal that it needs to be configured "together". Alternatively when building, we should at least check if this value is set to true and others are in their default state to reject the config?

[daschl]

LGTM overall, just some minor comments on docs

[idelpivnitskiy]

Sorry that it took so long to review. I like the approach, just some comments to make it stronger:

[idelpivnitskiy]

Everything lgtm, the last minor comments:

[idelpivnitskiy]

Great work, thank you! 🚀