Changes to Error responses

[IanGavurin]

[Repost of prior question, as it seems to have been missed (probably shouldn't have added it to a resolved post).]

We've had a number of our error handlers fail, seemingly due to changed formats on the error responses.

These don't include the expected "error_type", but instead alterantive information.

Seems to impact various error codes, at minimum these 2:

403:

{
	"error": {
		"code": 403,
		"message": "The caller does not have permission",
		"status": "PERMISSION_DENIED"
	}
}

We're also seeing this on 429:

{
	"error": {
		"code": 429,
		"message": "Resource has been exhausted (e.g. check quota).",
		"status": "RESOURCE_EXHAUSTED"
	}
}

These all used to be handled cleanly at our end, but now the client lib I'm using (Fitbit.NET) is falling over itself when trying to handle them.  I was going to create a patch for the lib, but I'm not clear what to expect now.. none of this seems to corrospond to the docs.

Could you clarify if this is expected, or some kind of bug?

If it's a permanent change, can the documentation be updated accordingly please!

[Gordon-C]

Hi @IanGavurin 

Thank you for reporting this problem.   I was not informed that our error messaging was changing, and have not seen these messages before.   I have a few questions for you

1. Are you purposely generating these errors in your application for testing the error handling in your app?
2. Are these the only error messages which you have noticed a change in the text?
3. I'm assuming for the 403 error, the access token you're using doesn't have the necessary scope to call the endpoint.   Can you tell me which endpoint you are calling?
4. For the 429 error, can you tell me what endpoints you are calling to generate this error?

Thanks!

[IanGavurin]

1. It wasn't originally - I was investigating a user reported issue with their data not showing up in our app.  Our logs showed local error handlers throwing and being picked up at the global level.  I have since done some experiementation to try and understand what was going on and the above examples are taken from a local debugging instance.

2. I can't be sure, but I've just run a couple of examples in my debugger.  Both 400 and 500 seems to be as expected (matches docs).  Some are easier to force than others - haven't tested all possibilities.

3. Good question on the endpoint - Ran a couple of examples:

Example A - user lacked "settings", Called devices endpoint
Response - as per docs

{
	"errors": [
		{
			"errorType": "insufficient_scope",
			"message": "This application does not have permission to access settings data. Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."
		}
	],
	"success": false
}

Example B - user lacked "heartrate", Called HeartRateIntraday endpoint
Response - NOT as per docs

{
	"error": {
		"code": 403,
		"message": "The caller does not have permission",
		"status": "PERMISSION_DENIED"
	}
}

4. I was able to cause another 429 while testing, and it's is still as above (not as per docs).  This particular example came from the ActivitiesSummary endpoint.

[for some reason the forum system won't let me post the url, even as a code block "The message body contains XXX, which is not permitted in this community"].

I'd note than our workflow dots around the endpoints collecting various things, so while the last request which hit the rate limit was on this endpoint, the quota will have been used across various endpoints.

Hopefully that can help narrow it down....

[IanGavurin]

Any update on this?

[sly_gryphon]

Hi Gordon, there is a defined standard for HTTP API error messages, RFC 9457. https://datatracker.ietf.org/doc/html/rfc9457

I suggest that your service should follow that standard, and many programming languages/frameworks may have built in support.