realm / realm-swift

Realm is a mobile database: a replacement for Core Data & SQLite
https://realm.io
Apache License 2.0
16.32k stars 2.15k forks source link

Not Able to Observe a 'SyncSubscriptionState' #7833

Open reveelapp opened 2 years ago

reveelapp commented 2 years ago

How frequently does the bug occur?

All the time

Description

Unless I missed something in docs, I cannot see a way in Swift to observe changes in the 'SyncSubcriptionState'.

The docs say it is possible to "watch" (which seems proper) on this page.

My setup is with storyboards (not SwiftUI). I am using Realm 10.25.2 with Xcode 13.3. Tried both SPM and Pods.

Thank you in advance!

Stacktrace & log output

No response

Can you reproduce the bug?

Yes, always

Reproduction Steps

I was expecting to use '.observe()' for changes in the 'SyncSubcriptionState'.

Version

Realm Swift SDK: 10.25.2

What SDK flavour are you using?

MongoDB Realm (i.e. Sync, auth, functions)

Are you using encryption?

Yes, using encryption

Platform OS and version(s)

iOS 14.8.1

Build environment

Xcode version: 13.3 Dependency manager and version: tried both SPM and Pods

dianaafanador3 commented 2 years ago

Hi @reveelapp at the moment you cannot observe the subscriptions status at the moment, but you can check at any moment for the current status of the it. What you can do is use our async update methods to wait for a subscription set to complete and data to be bootstrapped.

subscriptions.update({
            subscriptions.append(QuerySubscription<Person>(name: "person_age_15") {
                $0.age > 15
            })
        }, onComplete: { error in
            // You can check if the there is an error while subscribing to a query or you get error == nil if the subscription completes 
        })

or

try await subscriptions.update {
            subscriptions.append(QuerySubscription<SwiftPerson>(name: "person_age_all"))
        }
reveelapp commented 2 years ago

Hi @dianaafanador3 - thanks for confirming this!

My concern is that after a subscription is '.complete', what if thereafter it errors, etc. Hence the desire for observing the 'state' to handle any issues.

Could you provide an estimate on if or when observing will be available?

Thank you in advance!

dianaafanador3 commented 2 years ago

After the subscription set completes there should not be any errors associated to the subscription, any sync error will show in the errorHandler from the sync manager

app.syncManager.errorHandler = { (error, session) in
}
reveelapp commented 2 years ago

@dianaafanador3

Okay.

I do have an exhaustive '.errorHandler' built (excluding subscription states). Though since I cannot force such a subscription issue (e.g., '.error'), I cannot test/see how to handle it. It would be nice to handle them if possible... Can you provide some guidance how the subscription changes will present themselves via '.errorHandler'? -if it does happen in that rare case.

Thanks!

ejm01 commented 2 years ago

Hmm, yeah looking at the error types in RLMSyncUtil.h:60 there isn't an error code for what you're mentioning. I don't know what it would look like and what information it'd convey exactly, or if it'd even go there. But I think what you're asking for sounds reasonable. I'll leave this ticket open as an enhancement.

reveelapp commented 2 years ago

@ericjordanmossman - thank you - much appreciated!

Also, I have been tracking error codes from docs and those that pop up (varied or new from docs). I was able to force a new one for FS (via testing-app to force errors), which is error code '230' - it reads "Client attempted a write that is outside of permissions or query filters: cannot write to table "<CLASS>" before opening a subscription on it"

dianaafanador3 commented 2 years ago

Hi @reveelapp this happens when you write to a realm an object that it is out of view (meaning that it is not included as a query in subscriptions set). There is also a project which will include an specific and more detailed error for this.

reveelapp commented 2 years ago

@dianaafanador3 - yep - I know - thanks tho. I was able to force that one out through a race condition. I have built some apps to simply test errors (by force creating various errors), all for protecting production app usage. I have noticed that we have new errors that are not matching up with those docs I mentioned.