-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.x: Unexpected Flowable.flatMap(...) behavior while handling an upstream error #6825
Comments
Sources emitting an error are considered cancelled so it is completely legal to not call cancel on them. Use |
Thank you for looking into this. But I'm afraid I wasn't specific enough in my question above. In the following code snippet I expected error2 to never get emitted because error1 terminates the entire flow sooner that flowable2 emits error2. However error2 actually fired (triggered an UndeliverableException).
So my questions are:
|
|
Thank you very much for your support. |
Hi,
I've discovered an unexpected behavior of the Flowable.flatMap() operator leading to a possible subscription leak. Localized my problem in the following scenario:
Expected result: flatMap disposes flowable2 upon handling the upstream error.
Actual result: flowable2 remains subscribed after the entire Rx chain terminates because of the error.
Replacing the flatMap operator with concatMap fixes the problem (such a replacement is valid in my case). However I decided to raise this issue because such behavior of flatMap looks quite odd to me. Could somebody from RxJava team confirm whether my expectation is valid and the observed behavior is a defect?
I've reproduced this issue in a code snippet: https://gist.github.com/eugene-zolotko/b24cbc436bc0eab2ed5de539b9e4e312
I'm expecting this code to produce "flowable2 cancelled" output. But got "flowable2 error" instead, plus error2 gets thrown as UndeliverableException because it occurs after the entire chain is terminated.
The text was updated successfully, but these errors were encountered: