(Partially?) incorrect type annotation for onError callback

[oguzhanogreden]

Here I read that the callback will be passed an argument of type:

{
  message: string
}

I've tested this by passing an incorrect API key to init() and it led to a runtime exception.

Looking at the network response, the type annotation seems incorrect as your API returns:

{
  detail: string
}

[dabeeeenster]

Thanks - will take a look

[oguzhanogreden]

I appreciate the quick response! Can't see the priority here, so would you be able to help me further?

Should I consider this { message?: string, detail?: string} or would {detail: string} be enough?

[kyle-ssg]

I'll review this since there are several endpoints as well as the possibility of this being the result of a promise catch or perhaps a network timeout.

[gfrancischini]

Any updates on this issue? It seems that the onError is unreliable as of now and we would like to log problems to sentry.

[kyle-ssg]

The problem with this is that we don't know what the error could look like taking the following into consideration:

• Any unexpected exceptions
• Lack of internet connection
• Different possible API responses for scenarios such as invalid API keys, 404s etc.

Happy to take any suggestions here but I don't really see how we could guarantee the format of an error.

[gfrancischini]

Uhm.. What do you think about delivering the Error object instead of only the message? At least the Error object has the message and stacktrace properties that can help on figuring out where the error is happening

[kyle-ssg]

Apologies for the late response on this one, thanks for your suggestion. As of 3.16.0 onError will always send an Error object