Copy and pasting an observable can somehow give it properties of a different observable? Or maybe something else weird with error propagation and creation order of nodes.
See the attached patch for recreation instructions
Versions
In 6.3-0013 and 6.2 stable behaves as I describe above
In 5.3-0088 and 5.2 stable error state does not seem to terminate any reactive stream, they all seem to have retry behaviour.
To be honest I have a question
What should the OnError and OnCompleted behaviour in vvvv look like?
Technically I think an observer should terminate observing with either of those states, but with the vvvv provided reactive process nodes there is no obvious handling for this. Which makes using some of the lower level reactiveX operators like Retry, OnErrorResumeNext etc awkward.
Also could say that observer should always automatically reobserve whenever it terminates. that would be simple and seems to be what happens in 5.2.
for the 1. topic, i think the other retry overloads are just not wrapped. see the patch for a Retry (Count) [Reactive].
The Retry without Count retries until it succeeds.
general:
i think in vl, all of the (wrapped) reactive nodes don’t ever terminate/complete the observable.
i guess this is due to the fact, that if they terminate, they must be recreated. foreach mainly does OnNext. and if it does OnComplete, it creates a new (private) subject.
(@devvvvs please confirm)
if my assumption is right, we cannot use constructs like retry, because they rely on OnError.
i still could imagine a extended foreach region, that gives you an additional output-pin for OnError. Retry (Count).vl (9.7 KB)
I think it’s a problem that we don’t have a defined way to handle stream termination because
a) errors will happen
B) external libraries may use onCompleted
I like the auto retry behaviour of 5.3, certainly it’s very confusing in 6.2 that an observable stops functioning due to an error but there’s no obvious error in the UI.
But auto retry has to be an option, I think we need options to handle OnError and OnCompleted as well.
I put the retry above the ForEach because as far as I can tell even though the error happens in the ForEach it will also trigger OnError up the chain and put the original Observable into error state. So then it’s the original Observable that needs to be resubscribed to reset the entire chain. But I still feel I’m missing something here…
Does using Throw inside a ForEach [Reactive] actually trigger the OnError callback?
When I insert the Debug [Reactive] node anywhere in the test patch I provided above it never counts any OnError calls, even where Retry seems to be functioning (which should mean Retry is reacting on the OnError calls, but Debug isn’t? )
The change in behavior of the ForEach region was indeed not intended and will be fixed in upcoming 6.3 release. Thanks for bringing it up.
And what sebl says, if using the Retry node at all, it should rather be at the end of the pipeline and not the front. But it’s also true that the ForEach region of ours does not work well together with this operator because it doesn’t really complete.
So if you want to make use of the Retry node, you should keep the ForEach node out of the equation.
