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

observeOn schedules onError ... should it jump the line? #1680

Closed
benjchristensen opened this Issue Sep 11, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@benjchristensen
Member

benjchristensen commented Sep 11, 2014

onError events are put on the queue so they get emitted on the scheduled thread ... but they are at the end of the onNext events. Should they instead "jump the line"?

I think yes as an onError is supposed to act like throwing an exception which unravels the stack immediately and discards all state, including data in queues.

This is based on Rx Design Guideline 6.6:

6.6. OnError messages should have abort semantics
As normal control flow in .NET uses abort semantics for exceptions (the stack is unwound, current code path is interrupted), Rx mimics this behavior. To ensure this behavior, no messages should be sent out by an operator once one of it sources has an error message or an exception is thrown within the operator.

@benjchristensen

This comment has been minimized.

Member

benjchristensen commented Sep 23, 2014

Involving @headinthebox and @mattpodwysocki so we can verify what this behavior should be.

The design guidelines are not clear enough to make a decision as to how this should behave.

Consider this use case:

source.map(t -> r).observeOn(s).map(t -> slowR).subscribe(o)
  • source Observable emits infinite stream of ints
  • after 1000 are emitted, an error occurs in a mid-stream operator BEFORE observeOn
  • the error is caught and propagated via onError
  • the map AFTER observeOn is slow
  • currently all 1000 items are processed in queue and then onError is propagated

Should the onError "cut the line" as soon as it happens, or should it wait?

In this example it can take a long time to get through the queue due to the slow map function after the observeOn.

@headinthebox

This comment has been minimized.

Contributor

headinthebox commented Oct 1, 2014

Verified that in .NET onError does not cut the line, but I do think it makes sense to "follow the design guidelines", and for the delayed error behavior add an overload observeOnDelayError (since you may want to receive all values at the other end of the observeOn.

@benjchristensen

This comment has been minimized.

Member

benjchristensen commented Oct 2, 2014

Thanks for the confirmation, I'll proceed with this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment