Bad changeset (DOWNLOAD)

[euZebe]

Goals

Open a specific realm successfully.

Actual Results

All realms but one open successfully, data is synchronized as expected.

But when trying to open a realm for a specific user, I get the following error on realm client side :
```{"errorCode": 1, "message": "Bad changeset (DOWNLOAD)"`}``

I tried removing all data from the realm, but I still get the same error.

I tried opening the realm with another device, so that I am sure there is no merge conflict, but still...

Logs

Here are Realm Server logs for the partition:

[
  "Binding to partition \"26ec020e-0aac-4e40-8804-a5aabc251889\" with existing file ident",
  "Session identifier is 2"
]

Partition:

26ec020e-0aac-4e40-8804-a5aabc251889

Logs:

[
  "Session was closed by Sync Server",
  "Session was active for: 0s"
]

Partition:

26ec020e-0aac-4e40-8804-a5aabc251889

Session Metrics:

{
  "downloads": 1
}

Error:

failed to complete history scan: error while doing history scan for session: sending MARK message after download failed: failed to write msg: WebSocket closed: failed to read frame header: EOF

Logs:

[
  "Connection was active for: 1s"
]

Steps to reproduce

I use a JWT authentication.

I can hardly consider this problem comes from my application code since every other user can open its realm.

Since the user realm is nearly empty, I could remove it, remove the user from my OAuth service and create it again, but before it, I would like to understand what is the cause of that problem, and be sure it won't happen again. 🤞

Version of Realm and Tooling

• Realm JS SDK Version: 10.0.0-beta.11
• Node or React Native: 0.62.2
• Client OS & Version: iOS simulator / Android device

[kneth]

@euZebe Thank you for reporting. We fixed a bug with sync in v10.0.0-beta.12 but your error message looks different.

@simonask What do you think?

[euZebe]

I can't use beta-12 because of that issue #3189
The workaround @kneth seems not to work.
That's why I am still working with the beta-11 (with a local change to add a missing from keyword).

[kneth]

@euZebe Can you reproduce it with node.js?

[euZebe]

@kneth It works with both beta-11 and beta-12 on node.js.

[kneth]

@euZebe

It works with both beta-11 and beta-12 on node.js.

Thanks for trying it out.

Does it only happen for one user or do you see it for multiple users?

[euZebe]

@kneth I tried for a few users ; only one fails.

[euZebe]

Things become more problematic ; my tester reproduced it on another realm. No idea what happened ; he just used the iOS app basically.

[fronck]

@euZebe We're still investigating this issue. Are you, by any chance, using the deleteRealmIfMigrationNeeded flag in config of your realm?

[euZebe]

I didn't know that flag. No, I don't use it.
Since that day, I made some changes in my schema, I had to terminate sync then restart it, which solved this error. And I upgraded to beta-13 monday. This error didn't happen again.

[fronck]

That's great. Presumably the fixes in the latest betas did the trick.
I'll close this ticket. Feel free to reopen if needed.

Thanks for reporting.

[promit13]

I keep getting this error. It goes away for a while when I delete any one of the schema and re-initialise sync. And I add back the schema again, the app works fine. And again after a while this error re-appears. I cannot figure out what could be the issue. I have realm 10.0.0-beta.13.

[nirinchev]

Are you by any chance inserting documents in MongoDB directly or via GraphQL?

[promit13]

Yeah ... we are building web app and mobile app. Mobile app uses Realm Sync to query and insert document. But web app uses GraphQL to insert and query documents in MongoDB. Is it the reason behind this issue ?

[nirinchev]

Hm... GraphQL should be fine unless you're hitting an issue with inserting int64 values via GraphQL. Essentially, because int64 isn't representable in json (and thus GraphQL), the server uses a string as the only way to represent int64 losslessly. The problem is that, due to a bug, it inserts the string value in MongoDB rather than convert it to a int64. This then causes issues when synchronizing the document because it no longer conforms to the predefined JSON Schema. We're aware of both issues and are working on fixing them.

In the meantime, the only viable workaround I know of is to use int instead of long in your JSON Schema definitions.

If, however, you're not inserting objects, containing int64 properties via GraphQL, that would invalidate my theory and we'll need more information. In that case, can you please open a new issue or a support ticket where you provide as much information as possible about how you experience the issue and, ideally, and actions that you know of that can trigger it.

[promit13]

@nirinchev thanks for the clarification. Looks like we have int64 properties in our database and it might be the reason behind the issue.