Faulty `SingleQueryChange` event when merging remote and local object

There is an inconsistency in the notifications reported from https://github.com/realm/realm-kotlin-samples/blob/main/MultiplatformDemoWithSync/shared/src/commonMain/kotlin/io/realm/kotlin/demo/model/CounterRepository.kt#L90

The issue is observed when initializing a new instance of the app when there is already data on the server side. Thus, creating a local Counter-object with same primary key as already existing on the remote side. When the remote data is synced the emitted events are not as expected and not consistent across platforms:

On Native (iOS/macos) the emitted changes are:

SingleQueryChange: io.realm.kotlin.notifications.internal.InitialObjectImpl@27e15e8
SingleQueryChange.obj: io.realm.kotlin.demo.model.entity.Counter@2dd17d8

Followed by

SingleQueryChange: io.realm.kotlin.notifications.internal.DeletedObjectImpl@2152478
SingleQueryChange.obj: null

Where as on Android the emitted events are:

SingleQueryChange: io.realm.kotlin.notifications.internal.InitialObjectImpl@883a296
SingleQueryChange.obj: io.realm.kotlin.demo.model.entity.Counter@19a1e17

Followed by:

SingleQueryChange: io.realm.kotlin.notifications.internal.InitialObjectImpl@51c7433
SingleQueryChange.obj: io.realm.kotlin.demo.model.entity.Counter@af733f0

[cmelchior]

Hm, I think that is intentional…i.e. the Notification system is allowed to handle multiple transactions at once and combine their notification. But we probably failed to consider the implications in our implementation of SingleQueryChange.

I suspect that we might have to fake some of these notifications.

What is concerning though is that @rorbech is seeing a DeletedObject on Native…I don’t have a good explanation for that one … Unless…it is DiscardLocal client reset happening without us noticing it? 🤔

[rorbech]

The object deletion events was caused by re-running tests that creates objects with statically assigned primary keys but different partition values. Sync will correctly delete new objects with the same primary key even though the partition value is different because it is backed by a collection that only uses the primary key-field as primary key.

The behaviour in the sample demo app must have been due to old sync history with same situation (same primary key object but different partition key) laying around generating the same deletion events. Disabling and reenabling sync flushed that history and eliminate the issue.