BadChangeSet Error: failed to validate upload changesets: ProtocolErrorCode=212

Hello everyone,

I am new to MongoDB Realm, however had some experience with MongoDB.

Before any comments about the same problem, I already have been to all discussions and nothing have helped me yet.

I have consulted these discussions:

But sadly, either the mentioned solutions doesn’t work for me or I am not able to understand those.

I am currently using Realm in Nodejs. I have partition key as restroName while activating sync. But constantly I keep getting 212 error while I connect using:

const realm = new Realm({
        schema:[ItemSchema],
        sync:{
            user:user,
            partitionValue: user.id,
        }
    })

failed to validate upload changesets: SET instruction had incorrect partition value for key “restroName” (ProtocolErrorCode=212)

When i try to use partionValue: “anything”, it gives:

user does not have permission to sync on partition (ProtocolErrorCode=206)

So I assume it needs to be the user.id on the partitionValue but I want to store data in the realms with restroName.

Also I always clear the realm data (wipe it) before I make changes.

I hope I can get help.

What version of realm-js are you using? What do the server-side logs say? What does your sync configuration look like?

For permissions you can take a look at this doc -
https://docs.mongodb.com/realm/sync/permissions

I am using realm-js version 10.0.1.
The server log says

Error:

failed to validate upload changesets: SET instruction had incorrect partition value for key "restroName" (ProtocolErrorCode=212)
Partition:
myuserid

Write Summary:
{
  "item": {
    "inserted": [
      "5fd1d25d53e7d937bcc478bb",
      "5fd31c6b14e8f1e40bc40bb8",
      "5fd34db34824056b8c62445a",
      "5fd1d22be3b5216bdb0af01b"
    ],
    "deleted": [
      "5fd1d22be3b5216bdb0af01c",
      "5fd1d25d53e7d937bcc478bc",
      "5fd31c6b14e8f1e40bc40bb9",
      "5fd34db34824056b8c62445b"
    ]
  }
}
SDK:
node.js vRealmJS/10.0.1
Platform Version:
v14.15.0

I see the problem here because I have the partition key as restroName and instead I gave partition value my user.id.
When I set the partition key as _id, I receive the error:

attempted to bind on illegal realm partition ("\"5fbe16ffa476d2d81049ef6d\""): expected partition to have type objectId but found string (ProtocolErrorCode=204)

I have set the id as BSON.objectId, then I get this:

Error:

Ending session with error: user does not have write access to partition (ProtocolErrorCode=206)
Logs:
[
  "Session was active for: 1s"
]
Partition:

ObjectID("5fd1d22979ac94bd7d61fab7")
Session Metrics:
{
  "downloads": 1
}
SDK:
node.js vRealmJS/10.0.1
Platform Version:
v14.15.0

I have tried my best to do everything I found on other discussions.
Ok, here is the real deal.
I would like to create a Realm App where the users who work in the same restaurant can read and write the data.
For this I configured partition key in RealmSync as “restroName”.
Then for permissions, where I think I messed up, I set permission as users can read and write their own data.

{
  "%%partition": "%%user.id"
}

The errors when I change the partition key are mentioned above.
What would be the best thing for me to do? Should I make custom authentication function and store restroName in Atlas and set permissions as “%%partition”: “%%user.customData.restroName”. I am currently trying to do so but I think that won’t help either.
Please guide me through it, I think I am misunderstanding some things in the documentation.

@Maneez_Paudel If I understand your use case correctly then yes I would set the partitionKey as the restaurant name and use custom user data as a way to store which restaurants a user has access to. You can see an example of this here which uses projects instead of restaurants -

You’re on the right path with the permissions expression but it is flipped - see here:
https://docs.mongodb.com/realm/sync/permissions#permissions-based-on-user-data

Thanks @Ian_Ward, I already did so, and it worked using the custom data

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