Skip to content
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

response.EnsureSuccessStatusCode is preventing validation errors being sent back to the calling code. #3057

Open
WhoopieMonster opened this issue Oct 5, 2024 · 2 comments
Labels
documentation Improvements or additions to documentation supportability

Comments

@WhoopieMonster
Copy link

WhoopieMonster commented Oct 5, 2024

Microsoft.Identity.Web Library

Microsoft.Identity.Web

Microsoft.Identity.Web version

3.2.0

Web app

Sign-in users

Web API

Protected web APIs call downstream web APIs

Token cache serialization

In-memory caches

Description

When calling a downstream api I would expect to receive the payload regardless of the success status of the http call. The use of response.EnsureSuccessStatusCode is preventing this from happening.

There are plenty of scenarios where this behaviour should be supported, the most obvious being validation errors.

Reproduction steps

Intentionally call a downstream api with an invalid payload causing a failure, such as model validation, generating a non-successful http status code.

Error message

A new HttpRequestError is thrown.

Id Web logs

No response

Relevant code snippets

var result = await downstreamApi.PostForUserAsync<object, object>(
"my_api",
data,
options =>
{
    options.RelativePath = $"my_api/my_data";
});

Regression

No response

Expected behavior

Alongside the exception I would still expect to receive the payload from the downstream api, allowing me the freedom to decide what to do with it.

@WhoopieMonster
Copy link
Author

Appreciate this is light on samples - but the issue is very straightforward.

@zminot
Copy link

zminot commented Oct 10, 2024

You should be able to use the generic method CallApiForAppAsync with the proper method settings in downstreamApiOptions to receive the actual response. Had a similar issue too, took that route, and that seemed to work for my case.

Though, I found this as a viable alternative by searching through GitHub issues and finding the recommendation. It might be a good change to make this more obvious, but I'm not exactly sure how.

@jennyf19 jennyf19 added documentation Improvements or additions to documentation supportability and removed untriaged needs attention labels Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation supportability
Projects
None yet
Development

No branches or pull requests

3 participants