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

Documentation for beforeError has incorrect usage of response.body #446

Open
rlwhatley3 opened this issue Jul 27, 2022 · 4 comments
Open
Labels

Comments

@rlwhatley3
Copy link

Documentation States:

hooks: {
		beforeError: [
			error => {
				const {response} = error;
				if (response && response.body) {
					error.name = 'GitHubError';
					error.message = `${response.body.message} (${response.statusCode})`;
				}

				return error;
			}
		]
	}

but the response.body is a readable stream.

        beforeError: [
            (error) => {
                const { response } = error;
                if(response && response.body) {
                    console.log('this is a readable stream', response.body)
                    error.name = response.statusCode;
                }
                return error;
            }
        ]

I need to be able to get the response body for failed calls, to render error message that are set on the backend via a json api. The only way to do this currently is to set the throwHttpErrors to false AND not use .json, which leads the code to have to check returned objects responses as a whole instead of as a json, and to check for specific fields etc to determine if its in error.

@ortonomy
Copy link

also need to read responses from a json API in response.body if an error. Doesn't seem to be automaticlaly parsed?

@ortonomy
Copy link

ortonomy commented Jul 31, 2022

I solved it like this @rlwhatley3 . Not ideal, considering the reason to use ky is to remove boilerplate like making calls to Response.json(), but it does work.

(my error message is potentially a collection of errors, so that's the only reason it's a string[]

beforeError: [
      async (error) => {
        if (error.response) {
          try {
            const errorData = await error.response.json()
            error.message = (errorData as { message: string[] }).message.join(
              ','
            )
          } catch (e) {
            console.error("couldn't parse error response for specific message")
          }
        }
        return error
      }
    ]

@ShivamJoker
Copy link
Contributor

@sindresorhus is the fix impossible to add in library itself?

Seems like this issue has been open since almost 3 months.

I would love to contribute.

@sholladay
Copy link
Collaborator

This is a mistake in the documentation. error.response is a Response and as such, error.response.body is a ReadableStream, which doesn't have a message property.

I think that example was written with the assumption that we would automatically parse the body and the message would be in the JSON received from the server. However, for now, Ky doesn't automatically read the response stream. You have to call await error.response.json() or other body methods to read and parse the body.

The example could be updated to something like this:

hooks: {
	beforeError: [
		async error => {
			const {response} = error;
			if (response) {
                                const { message } = await response.json();
				error.name = 'GitHubError';
				error.message = `${message} (${response.statusCode})`;
			}

			return error;
		}
	]
}

In the future, I think it would make sense for us to have something like error.json() to do some of the same things that ky().json() does, such as handling an empty response body more gracefully than response.json() does. Maybe even to auto-parse the body and put the result at error.payload or something like that. But until then, the example above will have to do.

@sholladay sholladay changed the title response.body is a readable stream instead of response body Documentation for beforeError has incorrect usage of response.body Jun 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants