Improve Client Facing Errors

[zombieobject]

Is your feature request related to a problem?

"So, the issue is pretty simple: when using the RN SDK on iOS & Android, if there is an issue, it usually raises an exception, but the exception contains no information about what happened (status code / error message)" - Noe Mazlieu

Describe the solution to the problem

"So our goal is pretty simple: be able to have more information about an error when it is raised by the XMTP RN SDK. We can focus on 429 rate limited first, but globally, it makes sense for the developer to know what failed when using your SDK, so I think working on this more globally makes sense. It enables us integrator to understand if our code is wrong, if the XMTP network has an issue, or something else." - Noe Mazlieu

Describe the uses cases for the feature

Heavily testing the application on the the same WiFi network will trigger rate limiting This can be observed by inspecting HTTP traffic and noting the HTTP status code 429. This will trigger the following user facing error:

Error: The operation couldn't be completed. (XMTP.ApiClientError error 1.)

Additional details

"We can focus on 429 rate limited first, but globally, it makes sense for the developer to know what failed when using your SDK, so I think working on this more globally makes sense. It enables us integrator to understand if our code is wrong, if the XMTP network has an issue, or something else." - Noe Mazlieu

Related Tickets

Android - Issue 162: Rate Limiting Errors

[zombieobject]

@fabriguespe I replied to Noe in our Slack thread with a few follow up questions for this ticket. Adding here for transparency.

I have a few follow up questions:

1. Am I understanding you correctly that both Android and iOS do not give sufficient error messaging when rate limiting occurs in the form of an HTTP 429 status code?
2. What text would you like see in this error message?
3. Rate limiting can be really difficult and time consuming to reproduce. Can you also add a couple of easy to reproduce error scenarios using the iOS SDK that I can track down at the same time? This will give me an opportunity to not only investigate the rate limiting issue but also take care of some quick wins in tandem. I'll add these to the original ticket for tracking purposes and update the status with findings as I progress.

[zombieobject]

Ok, I think we can omit questions 2 and 3 at this point. I can reproduce a handful of errors that subsequently aren't rendered in a useful manner on the front end and they generally are emitted from common locations.

[zombieobject]

Ok, made progress on extracting the error types and corresponding messages. Looks like I can work this out without needing changes to the rust library interface. I still have some minor work to clean up some call sites, but this is promising.

[zombieobject]

I have a decent reusable update that should cover most of the currently supported libXMTP error scenarios. We may have some outliers but can catch them in additional issues as needed. I plan to finish up the call site validation tomorrow and if all goes as expected, I should land a PR for this by EoD.

Note that this will pass the strings supplied by the libXMTP library, which is an improvement over generic enum codes in place now. Translation, better user facing errors, etc... are out of scope; this is purely for client SDK developers and integrators.

[zombieobject]

The following pull request to address this issue is now up for review.

#277

[zombieobject]

A new release with these changes is pending team feature coordination. An update on the release timing will be forthcoming.

[zombieobject]

Version 0.8.16 of the iOS SDK has been released.

https://github.com/xmtp/xmtp-ios/releases/tag/0.8.16