Weird issue with Observable not reporting disposed state correctly

[grofit]

I have a test in my project where it attempts to destroy observables (and other data) which are used by other observables, and historically this used to work fine, however now I'm trying to migrate code over to R3 I am noticing an odd issue.

Given there is a lot of infrastructure and dont want to muddy the waters, here is a screen recording I took of the issue in flight (as a gif)

To my knowledge I am not running any multithreaded code anywhere, and as you can see the object is not disposed when we enter the code to Subscribe to the observable, but by the time the subscription has begun firing it realises its disposed somewhere and blows up.

Is this correct behaviour and if so how should I best work around this, as its only an issue I have noticed since moving to R3.

You can see the original tests passing here:
https://ci.appveyor.com/project/grofit/ecsrx/branch/master

Here is a branch of the above with migration to R3 where the tests dont work:
https://github.com/EcsRx/ecsrx/tree/feature/try-r3

Any advice would be great.

[neuecc]

Hmm, I'm sorry, but honestly, I don't really understand what you're asking about.
I can't tell if you're talking about Observable or ReactiveProperty,
and I don't know where the gif process starts or where it's looping.
It's difficult to interpret what you're concerned about from this issue.

[grofit]

Basically its an Observable is created at some point in time from some Observable.Interval(...) or similar call, but it looks like R3 is returning a ReactiveProperty. This part is all fine and I have no issue with it.

The problem is that when we go to subscribe to the Observable it is reporting that it is not disposed, however when it actually executes the Subscribe method it blows up because it is actually disposed and Subscribe shouldnt be called with a disposed Observable, but as the debugging shows it is not disposed at the point of calling the subscribe method.

So I think the main question is if Subscribe should maybe handle this scenario differently?

As within rx there is no exception thrown in this scenario, when one of the guys from our community went on a deeper dive this is what was discussed/found.

As they say if this is by design im happy for you to close the ticket, if its not or its an unforeseen scenario happy to discuss further, again sorry its so convoluted, but it turned out a lot of our users do this sort of thing so its a real world use case.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days.