Build HTTP request in declarative client Publisher #10626
Merged
+518
−278
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HttpClientIntroductionAdvice is refactored to ensure that binding to a new HTTP request will happen within the reactive context when using a Publisher return type in a declarative HTTP client. This fixes the issue of the same MutableHttpRequest instance being re-used on retry attempts when the client is annotated with Retryable, which can lead to an incorrect state when used in conjunction with client filters that modify the request, for example by adding header fields. This makes the reactive behavior consistent with the blocking behavior. Tests are enhanced to check that the expected number of new request instances are constructed and bound when using Retryable with the declarative HTTP client.
yawkat
approved these changes
Mar 20, 2024
...nt-core/src/main/java/io/micronaut/http/client/interceptor/HttpClientIntroductionAdvice.java
Outdated
Show resolved
Hide resolved
...client/src/test/groovy/io/micronaut/http/client/retry/HttpClientRetryWithFallbackSpec.groovy
Show resolved
Hide resolved
timyates
approved these changes
Mar 20, 2024
...nt-core/src/main/java/io/micronaut/http/client/interceptor/HttpClientIntroductionAdvice.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Tim Yates <tim.yates@gmail.com>
timyates
approved these changes
Mar 20, 2024
...nt-core/src/main/java/io/micronaut/http/client/interceptor/HttpClientIntroductionAdvice.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Tim Yates <tim.yates@gmail.com>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
HttpClientIntroductionAdviceis refactored to ensure that binding to a new HTTP request will happen within the reactive context when using aPublisherreturn type in a declarative HTTP client.This fixes the issue of the same
MutableHttpRequestinstance being re-used on retry attempts when the client is annotated with@Retryable, which can lead to an incorrect state when used in conjunction with client filters that modify the request, for example by adding header fields.This makes the reactive behavior consistent with the blocking behavior.
Tests are enhanced to check that the expected number of new request instances are constructed and bound when using
@Retryablewith the declarative HTTP client.Background:
The prior inconsistency in behavior was found while searching for the root of a Micronaut Security issue where it was shown that the Authorization header was being added multiple times when using
@Retryablein conjunction with the declarative http client and theClientCredentialsHttpClientFilter:micronaut-projects/micronaut-security#1619
The additional header values only get sent when returning a reactive type from the declarative client method. This was traced to the difference in the way
DefaultRetryInterceptorimplements retry for blocking methods vs reactive methods. In the blocking case, the retryable method gets re-invoked, whereas in the reactive case the returnedPublisheris simply re-subscribed. This results in any state that is captured from outside of the Publisher lambda(s) being re-used in subsequent retries.HttpClientIntroductionAdvicewas building and binding the HTTP request prior to constructing thePublisherto be returned in the reactive return type code path, resulting in the sameMutableHttpRequestinstance from the first request being used on all subsequent retry attempts.Note For Reviewers
In order to detangle the request construction and binding to make it able to be done within a Publisher, I broke the prior
interceptmethod ofHttpClientIntroductionAdvicedown into a series of smaller methods. This is making the diff on that class a bit of a mess.