kitsu throws away http return status about kitsu HOT 9 CLOSED

HTTP status codes are only available in the JSON:API error responses or an axios error response object if there's no JSON:API error body.

However thrown errors are currently consumed by the get/post/etc methods and their catch is returning them instead of rethrowing the errors. So axios errors disappear and JSON:API errors are currently accessible with:

const { errors } = await api.get(...)

An easy fix for a simple oversight, but a breaking change for how errors are handled by clients, so will require a 5.0.0 release.

Errors should then be accessible with:

// Async/await
try {
	const { data } = await api.get(...)
} catch (err) {
	err.errors
}

// Promise
await api.get(...)
	.then(res => { res.data })
	.catch(err => { err.errors })

from kitsu.

Actually its probably far better to just return the axios response error object itself to provide consistent HTTP status access and easier debugging with being able to check what was called/headers

{
	Error: Request failed with status code 404
    config: { ... },
	response: {
		status: 404,
      	config: { ... },
      	data: { 
			errors: [ ... ]
		}
	}
}

Making accessing JSON:API errors:

err.response.data.errors

from kitsu.

How would I tell the difference between an axios error and a kitsu error (e.g. serialisation error)?

And I'm not quite sure what the snippet above is supposed to represent, it doesn't look like a valid object - is it missing some quotes?

from kitsu.

Errors thrown by the package remain unchanged.

That's just what stack traces look like. The Error: ... is the thrown error message and the objects below it are whats accessible in the catch block through the Error's properties.

from kitsu.

Alright so for 5.x migration guide:

Network Errors (Axios)

Network errors contain the request and response settings used by Axios. Accessing these from kitsu errors in 5.x:

catch (err) {
	err.name // 'Error'
	err.message // 'Request failed with status code 404'
	err.config // Object containing everything used to send the request
	err.response // Same as config, but for response
}

JSON:API Errors

In 5.x, if a JSON:API error is found in this, kitsu copies them to the error's top level for destructuring. They're also accessible from err.response.data.errors:

catch (err) {
	err.name // 'Error'
	err.message // 'Request failed with status code 404'
	err.config // Object containing everything used to send the request
	err.response // Same as config, but for response
	err.errors // Array of JSON:API errors: { title, detail, code, status }
}

In 3.x and 4.x, JSON:API errors are found and replace the axios error entirely, but were not thrown:

const { data, errors } = await api.get(...)
errors // Undefined or an array of JSON:API errors

kitsu Errors

Unchanged from 3.x and 4.x, if there is an error thrown by kitsu itself, then you only have:

catch (err) {
	err.name // 'Error'
	err.message // 'POST requires a JSON object body'
}

from kitsu.

Released a beta - 5.0.0-beta.1, or install with kitsu@beta

from kitsu.

After checking the usage of kitsu on GitHub, this probably wont be a breaking change for anyone so will be a 4.5.0 release soonish.

from kitsu.

Thank you for the extensive explanation and documentation!

from kitsu.

Added in 4.5.0

from kitsu.