You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the exact same scenario, when calling client.users.me(), we receive an error as follows:
{name: "Get Identity",message: "This action requires authentication to continue",code: "unauthenticated"}
Is this a different error and by design? I notice "unauthenticated" rather than "unauthorized".
We were expecting a response as in the first example, i.e. an HTTP status code in the code field, but if this is by design perhaps we can add the "unauthenticated" code check to our HTTP handlers.
Hi.
The SDK error handling is not particularly consistent across different domains (auth, accounting, projects, etc.).
We are planning to address this in the next little bit, but for now the differing error responses is expected.
Error responses are inconsistent across resource types (eg. /accounting,
/projects, etc.) and all the handling was done in a single method that
caused inconsistencies (eg. code 401 vs unauthorized, wrong messages,
etc.).
This refactors the error handling so each resource type has its own
method, allowing us to correctly populate the error objects. This
also renames the fields `code` and `number` to `statusCode` and
`errorCode` for clarity.
This helps address [issue 506](#506)),
though it does not solve that completely as the various resources are
still inconsistent in their messaging, but at least the SDK doesn't make
the problem worse.
When making API requests using the FB client and an expired auth token, different REST endpoints return different error messages. For example:
List Projects
When calling
client.projects.list()
, we get a nicely formatted http 401 error as described in the docs like so:Get Identity
In the exact same scenario, when calling
client.users.me()
, we receive an error as follows:Is this a different error and by design? I notice "unauthenticated" rather than "unauthorized".
We were expecting a response as in the first example, i.e. an HTTP status code in the
code
field, but if this is by design perhaps we can add the "unauthenticated"code
check to our HTTP handlers.See MRE here
The text was updated successfully, but these errors were encountered: