Reactive Retry Bug

Found two bugs with the Reactive retry behaviour and error handling

see also this thread
Reactive Retry - vvvv gamma / question - Forum

Bug1

The Retry [Reactive] node only allows one retry.

Bug2

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.

ReactiveOnErrorRetryTest.vl (102.6 KB)

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.

Hi Toby,

nice to share that reactive journey.

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.
image

(@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)

btw. why did you place the retry node before the foreach? i don’t know, but intuitively i’d put them after.

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.

another playground with some findings i found interesting:
Reactive.7z (61.1 KB)

image

another question is why does this throw at all?
from the stacktrace, i suspect some service collecting and throwing exceptions.

when i attach vs, i see this line in the output window:
Exception thrown: 'System.Exception' in System.Private.CoreLib.dll

but i couldn’t find where the exception is actually thrown.


maybe that is not the desired behaviour in all cases (e.g. cases like in this thread)

OnErrorException.vl (6.0 KB)