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

User Info fetcher: Improve http request error output #509

Closed
2 tasks done
Tracked by #477
NickLarsenNZ opened this issue Jan 31, 2024 · 1 comment · Fixed by #510
Closed
2 tasks done
Tracked by #477

User Info fetcher: Improve http request error output #509

NickLarsenNZ opened this issue Jan 31, 2024 · 1 comment · Fixed by #510
Assignees

Comments

@NickLarsenNZ
Copy link
Member

NickLarsenNZ commented Jan 31, 2024

Problem

Currently, we raise an error if the response to an HTTP request is 4xx or 5xx. We only know which part of the code the User Info Fetcher failed on. We have no HTTP response body in the error to give a hint to the problem. Eg: Is it a WAF or proxy issue, or are we reaching the idP but some configuration is wrong?

#[derive(Snafu, Debug)]
pub enum Error {
#[snafu(display("failed to get access_token"))]
AccessToken { source: reqwest::Error },

The difficulty in adding the extra indfoamtion is that the Reqwest library consumes the response when calling methods like .text() (or .json()), or error_for_status(), and we need a combination of both methods.

Suggested fix

Don't make use of error_for_status() (which simply checks for 4xx or 5xx errors) and instead manually check the status code, and then either response with the json(), or produce a Snafu error containing the text() (which is fallible, so consideration should be made how to handle that).

Acceptance criteria

  • Snafu errors for util::send_json_request
  • 4xx and 5xx still produce an error, but also contain any body output
    • Consider what happens if the decoding fails, or is very long.
@fhennig fhennig self-assigned this Jan 31, 2024
@fhennig fhennig moved this from Next to Refinement: In Progress in Stackable Engineering Jan 31, 2024
@NickLarsenNZ NickLarsenNZ changed the title Improve http request error output User Info fetcher: Improve http request error output Jan 31, 2024
@NickLarsenNZ
Copy link
Member Author

NickLarsenNZ commented Jan 31, 2024

@fhennig, here was my Snafu that I made for util.rs

#[derive(Snafu, Debug)]
pub enum Error {
    #[snafu(display("failed to execute request"))]
    HttpRequest { source: reqwest::Error },

    #[snafu(display("failed to parse json response"))]
    ParseJson { source: reqwest::Error },

    #[snafu(display("response was an http error"))]
    HttpErrorResponse { source: reqwest::Error },

    #[snafu(display("response was an http error: {text}"))]
    Something { text: String },
}

That last one was the one most relevant to this issue. The rest would be necessary to return Snafu's regardless of this issue being solved.)

A failed attempt

I got this far before realising it won't work, and we should just use do response.status() rather than using response.error_for_status()

pub async fn send_json_request3<T: DeserializeOwned>(req: RequestBuilder) -> Result<T> {
    let response = req.send().await.context(HttpRequestSnafu)?;

    match response.error_for_status() {
        Ok(response) => {
            let json = response.json().await.context(ParseJsonSnafu)?;
            Ok(json)
        }
        Err(error) => {
            let text = response
                .text() // try bytes
                .await
                .unwrap_or("unable to decode response body as text".to_owned());

            Err(Error::Something { text })

            // Err(Error::Something {
            //     text: "blah".to_owned(),
            // })
        }
    }
}

@fhennig fhennig moved this from Refinement: In Progress to Development: In Progress in Stackable Engineering Jan 31, 2024
@fhennig fhennig moved this from Development: In Progress to Development: Waiting for Review in Stackable Engineering Feb 1, 2024
@NickLarsenNZ NickLarsenNZ moved this from Development: Waiting for Review to Development: In Review in Stackable Engineering Feb 1, 2024
@fhennig fhennig moved this from Development: In Review to Development: Done in Stackable Engineering Feb 1, 2024
@lfrancke lfrancke moved this from Development: Done to Done in Stackable Engineering Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants