I'm glad you posted this @isaac-weisberg I've been wanting to explain what's going on since your "lmao" post on another issue that shows effectively the same behavior (and for the same reason.)

RxSwift is not, and has never been, asynchronous by default. If you don't introduce asynchronous behavior, then it will be completely synchronous.

Your sharedSubscription Observable is synchronous. This means that when you call observer.on(.next(3)), the subscriber will immediately receive the Event, before the closure exits, and this is what is causing your issue.

You can solve this by introducing asynchronous behavior on your sharedSubscription, either by dispatching the observe.on(.next(3)) or by adding an .subscribe(on:).

You can also solve this by moving the .take(1) inside the flatMap.

Frankly, I don't run into these sorts of problems because I don't wrap synchronous work in Observable contexts like you did in your sharedSubscription and I recommend that you don't either. (except when testing, where all the work should be synchronous which also solves the problem you are seeing and makes testing much faster.)

Yeah... I mean, what other answer could I have expected here.

This library has some... you know...

It's what makes the library so easily testable. No need for async tests and test expectations. But yea, if you are inconsistent when introducing async behavior you will run into problems.

In production code. There is no need for something like your sharedSubscription Observable. That could easily be just a normal function { _ in 3 }. If you have a function that takes a long time to execute, then you would obviously want to run it in a scheduler (.subscribe(on:) is your friend here), if the function doesn't take long, then just put it in a map closure.

Yeah... I mean, what other answer could I have expected here.

This library has some... you know...

Like your previous post - you show nothing but disrespect for the time and work of people whose help you asked for.

Daniel has spent a massive amount of time and kindness to explain the limitations. If this library doesn't suit your needs, feel free to stop using it. We'll hopefully still be able to afford our daily life after losing a customer 🥲 (of this entirely open-source, volunteer-based framework)

If you are using it and need help, the way you're doing it in your last two posts isn't a way of getting it.

Good luck, and I'm locking this thread, too.