You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think what would be expected when there's an error is that it will retry the subscription when the inner observable emits - but just once.
Of course you wouldn't do interval() here, but imagine this is references a stream that emits when the connection get restored - From the point there was an error, every time that the connection is restored, this operator will create a new subscription to input$, without cleaning the previous ones.
IMO it should only resubscribe once per error.
Why am I not sure to raise it as a bug? Because the operator is marked as deprecated, recommending to use retry({ delay }) instead. However:
retry({ delay}) swallows errors when passing in an empty observable
retry(n) never swallows any error. After the amount of retries have failed, the error is propagated.
I would expect that passing in an observable to say when to retry that just completes without emitting means that the error should not be retried, and instead just thrown. If someone wants to capture the error, do something with it or just swallow it, we have catchError( which can be used just after retry.
This one is more to raise for discussion. I don't think it may be worth it changing the behaviour as it would just cause more confussion.
AGENDA ITEMFlagged for discussion at core team meetings
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This discussion has to do with 2 related operators that feel buggy, but I'm not sure if it can be raised as a bug.
retryWhen
resubscribes to the source when the notifier emits more than once, without cleaning up the previous subscription.playground https://stackblitz.com/edit/rxjs-hjjycs?file=index.ts
I think what would be expected when there's an error is that it will retry the subscription when the inner observable emits - but just once.
Of course you wouldn't do
interval()
here, but imagine this is references a stream that emits when the connection get restored - From the point there was an error, every time that the connection is restored, this operator will create a new subscription toinput$
, without cleaning the previous ones.IMO it should only resubscribe once per error.
Why am I not sure to raise it as a bug? Because the operator is marked as deprecated, recommending to use
retry({ delay })
instead. However:retry({ delay})
swallows errors when passing in an empty observableThis is as per documented https://rxjs.dev/api/index/interface/RetryConfig, so also not a bug. However, intuition says that this variation of the operator is doing too much.
retry(n)
never swallows any error. After the amount of retries have failed, the error is propagated.I would expect that passing in an observable to say when to retry that just completes without emitting means that the error should not be retried, and instead just thrown. If someone wants to capture the error, do something with it or just swallow it, we have
catchError(
which can be used just afterretry
.This one is more to raise for discussion. I don't think it may be worth it changing the behaviour as it would just cause more confussion.
Beta Was this translation helpful? Give feedback.
All reactions