Did Atlas App Service error codes change recently?

I’m logging in users through Email/Password authentication. I’m reading error codes to handle specific situations, like (1) when email confirmation is required after creating an account and (2) when user tries to create an account with an existing email address.


  • (1) “confirmation needed” would return error code 47
  • (2) “email already in use” would return 49.

After updating to a more recent version of realm-core and realm-cocoa:

  • (1) “confirmation needed” now returns error code 24
  • (2) “email already in use” now returns error code 25.

Is there a documentation for this change?

In this realm-core file, error code 25 is called value_duplicate_name, so at least I can see some logic for the (2) error, though error code account_name_in_use = 49 still exists. But error code 24 is linked to value_already_exists, which makes no sense for the (1) “confirmation needed” error.

Is there a logic behind this change? Handling realm errors when it’s so poorly documented is already a challenge, if you start changing the codes between versions it’s not maintainable at all anymore…

Ok so now I’m sure this is a bug. The code for (3) invalid credentials —like user entering a wrong password— is now function_not_found = 26 instead of invalid_email_password = 50 . This makes no sense at all.

I’m using Realm on iOS through SPM:

Realm v10.32.3
RealmDatabase v12.11.0

Also, “user not found” changed from 45 to 4…

Any chance the doc specifies the error codes, and we can actually rely on them?

Surprise, the codes changed again! The “confirmation required” error changed from 47 to 24 to 5.

It seems that every SDK update is gonna be a gamble that may break vital components of your app. Good luck.

@Jean-Baptiste_Beau - sorry for the inconvenience with the error codes changing across some Swift SDK releases. There was a project merged into Realm Core 13.18.0 (Swift SDK 10.42.2) that consolidated/updated a lot of the error codes that will hopefully help to make the numeric values more stable.

Of note, there are error code definitions in RLMError.h that you can use instead of the numeric values to potentially help mitigate the “ever-changing” error codes :smile:

Thanks @Michael_Wilkerson-Barker for your answer. I’ve answered on this issue. I think there is some issue with some constants. I will close this topic to avoid duplicates.

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.