Single and Completable takeUntil()

[ZacSweers]

In reading the original PR for Single, I saw Ben was OK with adding a takeUntil(Single/Observable) operator for Single later. I was wondering if this was still the plan, and if you would be open to contributions on this front. Same with Completable.

One caveat that I've thought of is that there's a potentially conflicting contact with Single and takeUntil() in the sense that takeUntil() calls onCompleted() in observables, but Singles will actually go to onError() if onCompleted() is called before any events are emitted (and by extension onSuccess()). Not sure what the clear path would be, but it seems like Singles would have to only unsubscribe and not propagate any notifications, differing from Observables and likely Completables in this regard.

[akarnokd]

Single.takeUntil still has to emit an onSuccess or onError; you need to emit a NoSuchElementException from the other Single.onSuccess. Unsubscribing the main and not emitting anything is bad because it keeps the subscribers hanging. I don't think it is worth it.

Completable.takeUntil is just completable.ambWith(other).

[ZacSweers]

The completable makes sense. For Single, do you think there's a feasible way to do a sort of takeUntil-like behavior where it completes/unsubscribes on the emission of another observable/single?

I'm working on some lifecycle handling for android, and a use case that's worked well in the past is to emit lifecycle events via behaviorsubject and then just takeUntil(lifecycleSubject.filter(e -> e == DETACH)). The idea is you want it to unsubscribe when the detach happens, and perhaps out of convenience we've always been using the fact that takeUntil would call onComplete and eventually cause it to unsubscribe.

[ZacSweers]

It seems like forcing an onSuccess or onError defeats the purpose of having a subscription that supports unsubscribe prior to that.

[akarnokd]

The best you can do with takeUntil is to signal an error, like CancellationException similar to how Future does.

[ZacSweers]

I see. Would that be something you guys would be open to as PR? Or at least consider making Single#lift() public since it's still experimental? Otherwise it doesn't seem like it's possible in the current API. Could catch existing NoSuchElementExceptions but there'd be no way to know if it was due to completion or cancellation.

Alternatively, would there be a simple way to potentially swallow that error upstream rather than force the subscriber to handle it?

[akarnokd]

We are open for PRs.

[akarnokd]

Closing via #3712

[ZacSweers]

Actually this just reminded me, would we want Single and Observable overloads for Completable, or just use amb and call toCompletable on those when passing them in?

[akarnokd]

Maybe, submit a PR and let's see the opinions.

[ZacSweers]

Will do, though likely not until this weekend or next week