Skip to content

WebClient.ResponseSpec.onStatus, Unexpected behavior when response body empty #4735

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

Closed
danielra opened this issue Jan 10, 2019 · 2 comments
Closed
Labels
status: superseded An issue that has been superseded by another

Comments

@danielra
Copy link

When I use the WebClient.ResponseSpec.onStatus method and try to create an exception that requires the response body content but the response body is empty, the Flux returned by a subsequent bodyToFlux call actually receives an onComplete instead of the expected onError.

To illustrate the behavior, I've created a sample project which reproduces the unexpected behavior in a test case here: https://github.com/danielra/webclient_response_spec_onstatus_empty_response_body_issue_repro
The project uses spring boot version 2.1.1.RELEASE as seen here.

When run via ./gradlew test --debug the test case (here) which has at least one character of response body content passes as expected - but the test case which has an empty response body (here) unexpectedly fails.

Please let me know if any further information would be useful.

@rstoyanchev rstoyanchev added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 12, 2019
@poutsma
Copy link
Contributor

poutsma commented Nov 14, 2019

With the introduction of ClientResponse::createException in 5.2, it is no longer necessary to consume the body bytes themselves. Using that method, I was not able to reproduce this issue.

Closing this issue for now, but let us know if there is something to look at.

@poutsma poutsma closed this as completed Nov 14, 2019
@poutsma poutsma removed the status: waiting-for-triage An issue we've not yet triaged or decided on label Nov 14, 2019
@rstoyanchev rstoyanchev added the status: superseded An issue that has been superseded by another label Nov 15, 2019
@rstoyanchev
Copy link
Contributor

Most likely superseded by #22825.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

No branches or pull requests

3 participants