Flexible Sync when offline

Hello,

So I have this app where I’m trying to use the flexible sync. It works perfectly when online but I want to start the realm also when there is no connection. Do I have to do something like having two realms and somehow enable the sync when online? Because I’m trying to start the app without connection but it crashes with a message that is not possible to access the host. I have found some questions in other languages but didn’t find a proper documentation for .NET about it. Thanks in advance!

Realm version: 10.17.0

Here is the log when I try:

[DOTNET] 2022-10-18 23:44:49.174 Error: Failed to resolve 'ws.us-east-1.aws.realm.mongodb.com:443': Host not found (authoritative)
**System.NullReferenceException:** 'Object reference not set to an instance of an object.'

[mono-rt] [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object.
[mono-rt]    at Realms.Sync.SessionHandle.<>c__DisplayClass26_0.<HandleSessionPropertyChangedCallback>b__0(Object _) in D:\a\realm-dotnet\realm-dotnet\Realm\Realm\Handles\SessionHandle.cs:line 461
[mono-rt]    at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()
[mono-rt]    at System.Threading.ThreadPoolWorkQueue.Dispatch()
[mono-rt]    at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
[mono-rt]    at System.Threading.Thread.StartCallback()
[libc] FORTIFY: pthread_mutex_lock called on a destroyed mutex (0x7c1ed31110)
[libc] Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 16670 (ogy.catalog.app), pid 16670 (ogy.catalog.app)

And here is the code I’m using to connect

public async Task ConfigureAsync()
        {
            RealmApp = Realms.Sync.App.Create("<app-id>");

            if(Utils.IsConnected())
            {
                _user = await RealmApp.LogInAsync(Credentials.EmailPassword(<email>, <password>));
            }
            else
            {
                _user = RealmApp.CurrentUser;
            }
            
            var config = new FlexibleSyncConfiguration(_user)
            {
                ClientResetHandler = new Realms.Sync.ErrorHandling.ManualRecoveryHandler(TratarErroSessao),
                Schema = new[] { typeof(Projeto), typeof(Campanha), typeof(GrupoTaxonomico), typeof(Coleta) }
            };

            try
            {
                Realm = Realm.GetInstance(config);
                var session = Realm.SyncSession;
                session.PropertyChanged += SyncSessionPropertyChanged;

                var subscriptions = Realm.Subscriptions;
                subscriptions.Update(() =>
                {
                    var defaultSubscription = Realm.All<Projeto>()
                        .Where(t => t.OwnerId == _user.Id);
                    subscriptions.Add(defaultSubscription);
                });
            }
            catch (Exception ex)
            {
                throw; 
            }
        }

This NRE is a bug in the .NET SDK and I have an idea for how to fix it, but I’m not sure if that’s the reason for the crash - what operating system are you running this on? I can also see pthread_mutex_lock called on a destroyed mutex in the logs, but I’m not sure if that’s coming from Realm code or from Mono - perhaps the first step would be to fix the NRE and then try again with that fix.

And to clarify the issue with the NRE - you’re subscribing for notifications on a local variable:

var session = Realm.SyncSession;
session.PropertyChanged += SyncSessionPropertyChanged;

When this variable goes out of scope, the session instance will be garbage collected, so you’ll stop receiving notifications. There’s a case where we don’t check for this and attempt to dereference the already collected instance. You can work around it by storing the session in a class level variable to ensure it lives for as long as you need it.

1 Like

I’m running on Android 10.0. But changing the session variable to a class scope worked. It does not crash anymore. Thanks a lot :slight_smile:

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