-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync session is resumed without explicitly calling resume
#6085
Comments
➤ nicola-cab commented: Maybe this is something Jonathan can help you with. |
➤ Jonathan Reams commented: I'm gonna need more information. Do you have debug-level logs? What does the repro for this look like exactly? |
I wrote a VERY simple test that calls
I get this output:
I can highlight the following. Pausing the session works just fine:
But it appears the session is resumed right after calling
|
➤ Jonathan Reams commented: Just want to run a theory by you. Looking at the logs we see |
I don't think so. The second "Realm opened" entry you see is our "writer" Realm, which is lazily initialised from the "reader" realm when we run a write transaction for the first time. This logic has been there for quite a while. |
➤ Jonathan Reams commented: So I'm trying to come up with a repro for this using the C API. So far I've got this integration test
And every time it does what I'd expect it to do:
I think it's time to do some pair programming on this with a debugger to try to figure out where the sync session is getting re-activated from. I'm pretty unconvinced that it's simply because realm_begin_write() is being called, but I don't know exactly how the lifetime of all the objects involved work in Kotlin. [~daniel.tabacaru@mongodb.com], could you work with [~eduardo.lopezgutierrez@mongodb.com] on debugging this since you're in the same time zone? |
I think we shouldn't be reviving the user if the Realm we're obtaining is frozen. Reviving for a live Realm is also a bit weird. We didn't specifically intend for opening a Realm to negate a previous call to suspend(); it's just that suspend() is a hack and doesn't put the sync session in a distinct state. It is long-standing behavior that users could plausibly be relying on, though. |
➤ Jonathan Reams commented: Just wanted to update this to say I'm still working on it. I've written a few solutions and kinda hate all of them. Hopefully I'll have a fix I'm happy with this week. |
Say I have two clients connected to the same app. Client A pauses its session and while being paused writes something. Client B will receive those updates regardless.
I can confirm the session becomes active again after calling
realm_begin_write
.The text was updated successfully, but these errors were encountered: