-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rest Client Reactive: don't retrigger client response filters when they fail #19498
Rest Client Reactive: don't retrigger client response filters when they fail #19498
Conversation
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 9f28a73
Full information is available in the Build summary check run. Test Failures⚙️ Gradle Tests - JDK 11 Windows #📦 integration-tests/gradle✖
⚙️ JVM Tests - JDK 11 #📦 extensions/smallrye-reactive-messaging-kafka/deployment✖
|
failures don't look related... |
9f28a73
to
cefd0c3
Compare
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building cefd0c3
Full information is available in the Build summary check run. Test Failures⚙️ JVM Tests - JDK 11 Windows #📦 extensions/resteasy-reactive/quarkus-resteasy-reactive/deployment✖
⚙️ Native Tests - Misc4 #📦 integration-tests/gradle✖
|
cefd0c3
to
404f64d
Compare
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 404f64d
Full information is available in the Build summary check run. Test Failures⚙️ JVM Tests - JDK 11 #📦 extensions/smallrye-reactive-messaging-kafka/deployment✖
⚙️ JVM Tests - JDK 11 Windows #📦 extensions/resteasy-reactive/quarkus-resteasy-reactive/deployment✖
|
404f64d
to
873c895
Compare
Failing Jobs - Building 873c895
Full information is available in the Build summary check run. Test Failures⚙️ Gradle Tests - JDK 11 Windows #📦 integration-tests/gradle✖
✖
|
the current failure is unrelated. I found some places that missed marking the abort chain as started. @stuartwdouglas do you want to take another look? |
@michalszynkiewicz so should we merge this one or wait? |
* This Handler is invoked before ClientResponseFilters handler. It changes the abort handler chain | ||
* to a one without the ClientResponseFilterRestHandler's so that the filters are not retriggered in case of failure |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just looked at the server case and in that case (in accordance to the spec) the following happens:
If there is an exception mapper, then the response filters are executed.
If there is no exception mapper, then the response filter are not executed.
Is there are a good reason to follow a different strategy here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are entirely different things. In the server world, an exception mapper maps an exception to a response.
For it, it may make sense to trigger response filters and react to the response.
In the client, we map a response to an exception that should be thrown to the user.
Or am I missing something?
Anyhow, the reason for the change is that if response exception filters are thrown on an exception when running response exception filters, they are triggered twice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess what you say makes sense, but I am not 100% sure yet.
But let's get it in and see in practice since it's obviously better than what we have
I think it's good. I had some doubts about merging because I did some changes after Stuart's review. |
fixes #19476