Secure scheduler release

[clementetb]

Describe your problem or use case

We require a method to ensure the secure release of schedulers after closing a Realm.

Sometimes, even after closing a Realm and disposing of the scheduler, it might still receive and execute a job, which could lead to a null pointer exception. This issue is concerning because the SDK manages the scheduler's lifecycle, and there's no clear way to determine when it's safe to release them.

While not always reproducible, this problem can be observed in the Kotlin SDK when initiating a client reset, closing the Realm, and releasing the scheduler.

Describe the solution you'd like

We like to release any scheduler safely.

Additional context

This issue might be related to #6429

[tgoyne]

Isn't this the realm_free_userdata_func_t callback to realm_scheduler_new? The SDK shouldn't be managing the scheduler's lifecycle.

[clementetb]

The realm_free_userdata_func_t isn't being triggered after closing the Realm.

[tgoyne]

That's just a bug, then.

[jedelbo]

IMHO you should not hold on the the scheduler, you create. Once you have assigned it to the configuration, you can release it.

[clementetb]

I have tried, but the capi scheduler free callback is not triggered.

[nicola-cab]

I think they are calling this API:
RLM_API realm_scheduler_t* realm_scheduler_new(....) and they are passing a callback that they expect to be invoked when the scheduler is released and this callback is never invoked (somehow), thus the scheduler is leaked in case they do open/close multiple times, and they do not use the same instance.
I can try to write a test tomorrow and see where the problem is...

[jedelbo]

@nicola-cab I am working with @rorbech on a resolution. The problem is that they store a shared pointer to the scheduler inside the userdata. So the scheduler is never released and hence the userdata is never released.

[nicola-cab]

ah great @jedelbo !... thanks for letting me know.