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

[benjchristensen]

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]

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]

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]

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