On 15/08/2025 12:39, Johan Vos wrote:
> Adding to this, I investigated what was exactly happening in my case.
> There was a Subscription with a few thousands recursive subscriptions,
> which were created by `and`.
> However, only a few of those subscriptions were still "active".
> When calling Sub
Adding to this, I investigated what was exactly happening in my case. There
was a Subscription with a few thousands recursive subscriptions, which were
created by `and`.
However, only a few of those subscriptions were still "active".
When calling Subscription.unsubscribe() in case of a combined sub
It's an interesting problem. I wrote some test cases, and came to this
solution to allow large amounts of chained subscriptions, while
maintaining Subscriptions as immutable constructs that will only
unsubscribe exactly the right subscriptions when using older references:
defaultSubscription and(S
You're right, this should preferably not happen. The implementation is
simple, but it does limit how many subscriptions you can chain.
The `combine` variant does not have the same issue.
I can rewrite it to avoid recursion, but it needs to be done very
carefully as the subscriptions chained with
Hi,
The current implementation of Subscription.unsubscribe() uses recursion to
unsubscribe the chain of subscriptions. This can lead to a
StackOverflowError in case there are many chained subscriptions. Running
the following code demonstrates this:
```
void testSubs() {
SimpleStringPr
