I am having an issue, that my sync/config.json file is being ignored by realm-cli.
When I change anything in functions/ I will get the correct behaviour when using realm-cli push.
However, when I change said config.json file, all I get is:
Deployed app is identical to proposed version, nothing to do
In case I update via the Realm UI, it saves correctly and next time I deploy, it pushes an “old version” of the config.json file.
Anyone experienced that issue before?
Hi @Thomas_Anderl,
Yes, I managed to reproduce the same error. The issue is with changing client_max_offline_days when Max Offline Time is not enabled. Once you change it’s value you can not push the app anymore.
The workaround is to click “Pause Sync” button at the Device Sync UI and then to deploy again using realm-cli push. On this way you will be able at least to apply the changes in the permissions.
We will check what is the issue with client_max_offline_days. You can leave it by default for now if it works for you.
Thank you for the response. It is actually likely that this started to happen when I first tried to change client_max_offline_days, but I am not 100% sure. But even if I don’t touch this field in my .json file, it behaves that way. Is this due to the same reason?
Edit: I pressed “Pause Sync”, tried to push my config and am still getting
Deployed app is identical to proposed version, nothing to do
Hm, It worked for me. Could you send your config.json? Is this option (max offline days) enabled or not on your app service device sync?
I sent yout the json via message. As I am not sure if I should post that here (my app is already in production). Offline time is according to the web UI disabled.
You have to set client_max_offline_days to the default value. Otherwise, it won’t work.
Set "client_max_offline_days": 30 in sync\config.json?
Then click “Pause Sync” and then deploy again using realm-cli push.
It should work.
I added
"client_max_offline_days": 30
and it still does not work. It keeps ignoring my config.
You will continue to receive this message “Deployed app is identical to proposed version, nothing to do” if the json settings are the same as the app service settings. Only changing client_max_offline_days is not considered as a change (it will be investigated).
If you change anything else in the config it will be uploaded. If there is no new changes different from the last upload, then the upload will be ignored.
So, I’m wondering whether your changes are not already uploaded. Or, are you sure that you are uploading to the correct App service? Could you try to login with realm-cli again with the app keys of the relevant Atlas project?
You can try to pull your app (realm-cli pull ) to another folder and then to compare the json files, whether they are identical indeed.
I am 99% confident, that I am pushing to the correct project. I also tried enable the automatic deployment from GitHub via the App Services UI and experienced the same issue. I just checked again by changing something in my functions and the function is changed correctly.
I can add my console output:
D:\GitHub\myApp\server\myApp-dev>git diff
diff --git a/server/myApp-dev/functions/onMessage.js b/server/myApp-dev/functions/onMessage.js
index f87b4c3..ec11c54 100644
--- a/server/myApp-dev/functions/onMessage.js
+++ b/server/myApp-dev/functions/onMessage.js
@@ -34,7 +34,7 @@ exports = async function (changeEvent) {
);
await context.functions.execute("sendNotification", receiverId, {
- text: message.senderName+ ": " + message.text,
+ text: message.senderName + ": " + message.text,
type: "MESSAGE",
});
-};
\ No newline at end of file
+};
diff --git a/server/myApp-dev/sync/config.json b/server/myApp-dev/sync/config.json
index 5e43a07..4b6538d 100644
--- a/server/myApp-dev/sync/config.json
+++ b/server/myApp-dev/sync/config.json
@@ -24,6 +24,9 @@
},
"createdAt": {
"write": false
+ },
+ "test": {
+ "write": true
}
}
}
D:\GitHub\myApp\server\myApp-dev>realm-cli push
Determining changes
The following reflects the proposed changes to your Realm app
--- functions/onMessage.js
+++ functions/onMessage.js
@@ -34,7 +34,8 @@
);
await context.functions.execute("sendNotification", receiverId, {
- text: message.senderName+ ": " + message.text,
+ text: message.senderName + ": " + message.text,
type: "MESSAGE",
});
-};
+};
+
? Please confirm the changes shown above (y/N)
As you can see, I changed the config.json and the realm-cli push does not detect the changes. I changed my functions afterwards too, and those are detected correctly. The git diff shows the differences I really made.
I have "client_max_offline_days": 30, in that file.
@Thomas_Anderl we will do some more investigations. Any additional details will be helpful if you have some.
Thanks, for your report.
I can give you any details that you need. What would help you? A “strange” behaviour is: When I change it in the UI it appears correctly. When I then run realm-cli pull, I however get the “old” version again. It seems that that version is stuck somewhere, or it somehow connects to the wrong project (I have prod and dev, but both projects have the same issue).
realm-cli apps list prints the correct project.
Hello @Thomas_Anderl,
Thank you so much for your patience. This has been discovered as a bug in the code and the team is investigating. I have escalated this again.
I will keep you updated as and when I have information.
Your patience is appreciated.
Cheers,
Henna
Hello @Thomas_Anderl ,
Could you please let me know if directly making changes from the UI would suffice at this moment? The team is working on releasing a new version of the CLI soon and it may take time to look at the issue in question.
I look forward to your response.
Cheers,
Hello @henna.s ,
changing in the UI only solved the problem until I make any other change again and the redeploy would “reset” it to the old version. Also I would prefer testing the configuration first extensively on dev (where I deploy stuff quite often), before I make such a big change on prod.
@henna.s @Desislava_St_Stefanova
I just did some additional testing (because I had to add a new Entity to my sync rules). I figured out that this one was correctly added to the sync. So I investigated a bit more and figured out, that field-level permissions are ignored. Document-level permissions are taken over correctly. Is this a known issue?
That means the max-offline-time and field level permissions are the ones that are (apparently) being ignored. Hope this helps in the investigation. Copying those manually, also works until they are overwritten the next time by my json. I copied my entire json manually into the UI and it was accepted and saved. With the next deployment however, the fields and max-offline-days will be removed.
Hi @Thomas_Anderl,
Due to your report and investigations, we have already two issues created and the App service team is on them. The first issue is about client_max_offline_days and the second one is about the permissions fields.
Thank you about your contribution!
Hey @Thomas_Anderl,
With regards to the issue with flexible sync field-level permissions not being push/pulled via the CLI - the team will be changing how flexible sync permissions are defined in the near future (within the upcoming release or two). More specifically, flexible sync permissions are being integrated into the Rules that are defined on the “Rules” page in the UI. In the App Configuration structure, this corresponds to the data source default rules and collection rules.
For a bit more context, the integration is being performed in order to make those rules be the single source of truth for all app services involving a MongoDB cluster (GraphQL, Flexible Sync, DataAPI, etc.). We’ll be performing a migration to convert everything over, so that shouldn’t require any additional action from your end.
In the meantime, if you need to deploy changes to the existing field-level permissions configuration for flexible sync, I’m afraid the UI is the best way to go about doing that; as you alluded to already, the local sync configuration will have to be manually kept in sync with the one deployed via the UI in order to develop locally off the latest version of the config (assuming there are changes that set field-level permissions). Sorry for the inconvenience.
Jonathan
Thank you @Jonathan_Lee for the insight. I was anyways wondering why these are two seperate things with a similar purpose. I am always happy about overall simplifications anf alignments. I assume however that the migration you mentioned will not affect me if my field rules are not manually deployed to the UI when the migration happens.
The migration will not “auto-pull” the app for you, so it should not immediately have an effect on anything locally (unless you pull, but that would be the same behavior as if you were to pull the app right now). To go into a bit more detail, the migration will look at whatever is defined under the “permissions” key in the flexible sync configuration at the time of running, and convert it to an equivalent permissions setup across the relevant data source default_rule.json / rules.json file(s). Thus, after the migration is ran, if you pull the app, you’ll be able to see those new file(s) in which permissions are stored, and should be able to modify the field-level permissions there.
One last thing to note: the “permissions” key in the flexible sync configuration will still exist after the migration (it just won’t be used anywhere); after all apps are migrated, we intend on removing that field completely.
Jonathan
Good to know, so there is more files than that I should sync between dev and prod.
I am deploying automatically to dev whenever my config changed (and prod on demand), but my field level permissions are ignored due to the issue you mentioned. That means when the migration happened I should have my config synced via the UI so the migration happens on them? Or are the field level permissions stored correctly behind the scenes and will migrate correctly?
As I redeploy my config pretty often on dev, it would overwrite it everytime. So currently I work without the field level permissions, so I dont have to update via the UI every time I change something.