Seeing a lot of "Sync -> Other" events in my Atlas app logs

Hi there :wave:

I’m using Realm with Atlas device sync on a MongoDB M10 cluster. My app is an Android budgeting app using the Kotlin SDK v1.11.1 and it has the following flow:

  • I’m authenticating the current user against Atlas with the user credentials
  • I’m starting a sync of the data of this account, basically it’s a sync of all the elements of my “Expense” collection where the user_id == the current user ID

Recently, I’m not really sure when, I starting seeing the following logs for such a flow:

What’s weird is that “Sync → Other” line with the following details when expending:

Logs:

[
  "changing query from existing query to new query",
  "Roles selected for sync:",
  "   readAll: [ ExpenseEntity ]"
]

Does anyone have an idea what it can be about? The query never changes for any user as the user ID is stable.

Thanks a lot in advance for your help!

Hi, this is a log we generate whenever we perform a bootstrap, change of query, or the permissions for a user changes. It seems like this is likely a new connection bootstrapping and this is just a log with some information about the bootstrap (roles chosen, new query, device information, etc).

I do not believe this has changed at all recently, but I can double-check that. Either way, I will add an action item to make the message of “changing query from existing query to new query” more specific depending on which of the 3 scenarios above is happening.

Best,
Tyler

1 Like

Hey @Tyler_Kaye many thanks for your answer.

Having the precise info of what changed would be a game changer here for sure. I can reproduce it every time on my own device so it’s probably the bootstrap scenario you’re describing but I’d love to know what changes precisely to know if I can avoid it.

Is this something you could check if I give you some logs access @Tyler_Kaye ?

Hi, I do not think anything has changed here, but either way, I am a bit unsure what the issue is that you want to avoid this log. If you send your application URL (in the browser) I would be happy to take a look at the backend logs for this, but there doesn’t seem to be anything wrong (this log is working as intended).

Best,
Tyler

Hello

How do you create your subscriptions?

I had the same issue and solved it by putting my subscription in the useEffect() function

  useEffect(() => {
     const createSubscription = async () => {
      await realm.subscriptions.update((mutableSubs) => {
        mutableSubs.add(realm.objects("Pet").filtered("userId == $0", Realm.BSON.ObjectId(user.id)), {name: 'PetSubscription'});
    
    })};
    createSubscription().catch(console.error);
    
  }, []);

if it is not in useeffect the subscription reload again and again and replace the previous subscription giving this message :

“changing query from existing query to new query”,

I hope this help

@Tyler_Kaye Yeah i’m not sure if I should be concerned or not, it’s just something new that I haven’t seen before so I just want to make sure I didn’t do something wrong. The URL is App Services

@cyril_moreau I’m not using JS but Kotlin, I’m just using initialSubscriptions when calling Realm.open, never mutate them afterwards.

Got it, yeah, this should not be an issue. It is just recording that new client connect with an empty subscription and then it is being added. I do suspect this might be an implementation detail of how you are setting up your subscriptions / how the Kotlin SDK is working under the hood.

@Tyler_Kaye Thanks a lot for taking a look.

My code is basically this (removed some details about recurring expenses that you might see on server logs for clarity as it doesn’t matter here):

          val realm = Realm.open(
                SyncConfiguration.Builder(
                    user = user,
                    schema = setOf(ExpenseEntity::class),
                )
                .name("${account.id}.realm") 
                .initialSubscriptions(rerunOnOpen = true) { realm ->
                    add(
                        query = realm.query<ExpenseEntity>(account.generateQuery()),
                        name = "${currentUser.id}:${account.id}:expenses",
                    )
                }
                .build()
            )

It didn’t change recently, neither the Kotlin SDK version changed recently on my app. Could that be a server change related thing?

I took a look at the server code and nothing here changed recently. It sounds like this is probably coming from using rerunOnOpen=true to the initial subscriptions blob. I suspect you likely want that to be false assuming the account information is not changing for a user in between closing and re-opening the application.

Ok this is basically necessary because the sync isn’t based on the userId (what I said on the first post) but on an accountId of this user. I simplified in my first post to make it more straightforward but maybe it makes things more complicated now.

So the real scenario is that when a user switch from one account to another, I just close the current Realm and reopen a new one with a different subscription, which needs the rerunOnOpen.

What’s weird is that this is the case since the very beginning and this new log appeared only recently, so I’m not sure if this is related but I doubt it.

Got it. I think that as long as you change the subscription when your account_id changes, you shouldn’t need to rerun the subscription each time you open the realm (that is my understanding of this page: https://www.mongodb.com/docs/realm/sdk/kotlin/sync/subscribe/#bootstrap-the-realm-with-initial-subscriptions)

Did you happen to upgrade versions of the SDK you are using possibly? Curious if something in there might be the difference that is causing the new log (though I would doubt it).

I need to re-run some tests but I’m pretty sure if I instanciate a new Realm on the same App using different subscriptions it doesn’t work. But I can’t really remember so maybe you’re right.

Nope, using the same SDK version for weeks now

Hey @Tyler_Kaye just wanted to give you a heads up: removing rerunOnOpen indeed fixed the problem so thanks a lot for the good pointer.

1 Like

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