Error Realm initialization with sync enabled due to mismatch schema is not calling onError function

[gfrancischini]

How frequently does the bug occur?

Always

Description

Check the following line:

realm-js/packages/realm-react/src/RealmProvider.tsx

Line 140 in 91de944

initRealm().catch(console.error);

It is calling the console.error directly. This way we cannot handle this error on user device.

We have configured the application to only open the realm for the first time after DownloadBeforeOpen.

Stacktrace & log output

[Error: The following changes cannot be made in additive-only schema mode:
- Property 'ObjectType.idInitialStatusIntegration' has been made required.
- Property 'ObjectType.idInitialStatusPDA' has been made required.
- Property 'ObjectType.idInitialStatusWeb' has been made required.
- Property 'ObjectType.nmCdField' has been made required.
- Property 'ObjectType.nmDisplayField' has been made required.
- Property 'ObjectType.nmIdField' has been made required.
- Property 'ObjectType.nmTable' has been made required.
If your app is running in development mode, you can delete the realm and restart the app to update your schema.]

Can you reproduce the bug?

Always

Reproduction Steps

1. Create a sample app
2. Set to open the realm for the first time DownloadBeforeOpen
3. Change the schema to a breaking schema
4. delete the local realm
5. Open the app again and see that the error is only printed at the console

Version

realm@12.6.2

What services are you using?

Atlas Device Sync

Are you using encryption?

No

Platform OS and version(s)

Android/iOS All

Build environment

Which debugger for React Native: ..

Cocoapods version

No response

[sync-by-unito]

➤ PM Bot commented:

Jira ticket: RJS-2794

[kneth]

@gfrancischini Thank you for reporting.

I believe that we should extend @realm/react with an option not to shallow the exceptions from Realm.open(). We can either rethrow the exception or call the onError callback (if defined).

[kraenhansen]

We agree an error like this should signaled differently than calling console.error:

1. Calling onError would be difficult, because that function takes the active sync session, but at this point no sync session has been established. To call it, we would have to break the API, allowing the onError to have null passed as the sync session argument, which is not ideal. So .. since this error isn't sync specific, we would most likely want to surface it differently than though the onError.
2. The RealmProvider could take an onError prop (admittedly, this name might be a little confusing as it conflicts with the onError passed through the sync config).
3. We could throw when the useRealm (or any of our other hooks depending on it).
4. Some other alternative that we haven't thought of? What's an idiomatic way to signal an error state from a React context provider? 🤔

[gfrancischini]

Hey any update on this issue? We are about to enter in homologation with our customer and we would like to be able to correctly log these errors to diagnose possible production problems

[kneth]

@gfrancischini

any update on this issue?

Currently we are logging the errors to help customers to diagnose problems. To provide a better solution, we would like the customer to give us feedback on the four items in the previous comment.

[gfrancischini]

The RealmProvider could take an onError prop (admittedly, this name might be a little confusing as it conflicts with the onError passed through the sync config).

I would call it onInitializeError or onRealmInitializeError as this is something that will only happen during realm initialization?

Or maybe onMountError? but I still prefer the above

We could throw when the useRealm (or any of our other hooks depending on it).
I think this is bad as it is not good to handle error on component renders

[kraenhansen]

I think this is bad as it is not good to handle error on component renders

I would expect developers to use an error boundary to handle these errors: Via getDerivedStateFromError on a class-based component or the resuable ErrorBoundary utility component.

[gfrancischini]

I feel that error boundaries should be used when something unexpectedly happens. A schema error is a handled error and in my opinion, should be handled differently. What we know/is expected should be handled different from the unknow.

But that is only my opinion really. So whatever solutions as long as we can show to our end user it is okay. What we cannot do is swallow the error as it is today as the app just crashes without giving user feedback

[kraenhansen]

I suppose the difference is if it's recoverable for the end-user or not 🤔 Some will be, others likely wont. I think this decision is the only thing holding back a fix for this. It's likely a simple change in code - and I'd like for us to get the API right 👍

[jaltin]

We are also in need of a way to detect model schema mismatch, so that we can tell the user what corrective action they can take, instead of the app just crashing.

Is there any planned fixed/change to allow us to detect this?

[andrei-tofan]

has a decision been taken on this? at the moment this is a blocker for our project because if this happens the user will be
stuck seeing a spinner and we want to show a message that a newer version of the app needs to be installed.