Issue while a app is on running on background via workmanager

Shreedhar73 commented 5 months ago

What happened?

I am uploading the video to api.video using theirs uploader plugin . video_uploader . They are using Workmanager to upload the video on background .

So when, I initialize the upload process, then terminate the app, (video continues to upload ) and then I try to reopen the app. I am getting ::

Realm at path '/data/data/com.yipl.onlyever/files/mongodb-realm/oe-phase1-tkmsy/653f43b64509e869245a3995/default.realm' already opened with different sync user.. Error code: 2013

Is there anyway I can handle this ?

Repro steps

I am using video_uploader to upload video to api.video .

Upload video , while uploading close the app
The video is uploading in the background
Re Launch the app , the above error throws : ' realm is already opened with different sync user

Version

3.13.0

What Atlas Services are you using?

Both Atlas Device Sync and Atlas App Services

What type of application is this?

Flutter Application

Client OS and version

Android 13

Code snippets

No response

Stacktrace of the exception/crash you're getting

No response

Relevant log output

No response

nirinchev commented 5 months ago

Can you post some code snippets that show how you open the Realm file? Also, what version of the Realm SDK are you using?

Shreedhar73 commented 5 months ago

@nirinchev final config = Configuration,flexibleSync(loggedInUser!, [...schemas]);

  if (isOnline) {
    realmHelper = await Realm.open(config);
  } else {
    realmHelper = Realm(config);
  }

I am on latest version : 1.8.0

nielsenko commented 5 months ago

I'm a bit rusty wrt. work manager, but I believe it will spawn separate processes (as of v.2.5.0 I think).

This means you are in multi-process territory, and while realm works fine in a multiprocess scenario there are a few caveats.

First and foremost, only one process can communicate with the sync server! In particular only one process can open the realm with a FlexibleSyncConfiguration.
The rest must use Configuration.disconnectedSync. The later requires a path, so pass that from the first, or specify it on both.
Also, make sure to add any subscriptions in the process owning the FlexibleSyncConfiguration before any process starts writing to the realm, as you otherwise risk loosing the data later to compensating writes.

There is work ongoing to handle this more seamlessly for users, ie. automatically elect a leader, and allow all processes to use a FlexibleSyncConfiguration, but it has not landed in core yet.

Shreedhar73 commented 5 months ago

@nielsenko

Thanks . Is there any way to determine if the realm at specific path has already been opened and use that data ?

nielsenko commented 5 months ago

Short of catching the exception, no.

But I would recommend that you always use Configuration.disconnectedSync in the code invoked from workspace manager, and only use Configuration.flexibleSync in your main app. The downside of this being that sync only runs while your app is open.

Or you can do your own leader election. Since you have a shared file system, it doesn't need to be very fancy. Note though that there are some tricky corner cases to consider, if the leader process ends without handing it over to another process.

You may also be able to configure the behaviour of WorkManager to use the original process (I vaguely recall that was how it used to work). If you manage to do that, remember to use the new App.getById method to get the app in the background isolate that the work manager code uses.

Also, while I'm not sure on the exact status, and things can be reshuffled, we are working on improving this.

Shreedhar73 commented 5 months ago

First one is a bit tricky since, the work manager being called is on the android side (handled by the library itself via method channel ) .

Shreedhar73 commented 4 months ago

I'm a bit rusty wrt. work manager, but I believe it will spawn separate processes (as of v.2.5.0 I think).

This means you are in multi-process territory, and while realm works fine in a multiprocess scenario there are a few caveats.

First and foremost, only one process can communicate with the sync server! In particular only one process can open the realm with a FlexibleSyncConfiguration.

The rest must use Configuration.disconnectedSync. The later requires a path, so pass that from the first, or specify it on both.

Also, make sure to add any subscriptions in the process owning the FlexibleSyncConfiguration before any process starts writing to the realm, as you otherwise risk loosing the data later to compensating writes.

There is work ongoing to handle this more seamlessly for users, ie. automatically elect a leader, and allow all processes to use a FlexibleSyncConfiguration, but it has not landed in core yet.

@nielsenko Hello. Are there any updates on this ?

nielsenko commented 4 months ago

If you are asking to the ongoing work in realm-core, then not yet, no. I'll be sure to return on this issue when there is news.

But I would not wait around for it, as there are a lot of higher priority work ongoing as well. The work-around using Flexible.disconnectedSync configuration, as described above, is still valid.

nielsenko commented 4 months ago

These are some related issues:

nielsenko commented 2 months ago

@Shreedhar73 We are not fully there yet, but realm-core 14.6.0 (and hence realm-dart 2.2.0 and forward) includes https://github.com/realm/realm-core/pull/7300 which is a pre-cursor for multiprocess-sync.

Shreedhar73 commented 2 months ago

@Shreedhar73 We are not fully there yet, but realm-core 14.6.0 (and hence realm-dart 2.2.0 and forward) includes realm/realm-core#7300 which is a pre-cursor for multiprocess-sync.

Thanks for the update. Looks promising .

realm / realm-dart