-
Notifications
You must be signed in to change notification settings - Fork 181
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
Context cancelled should be respected #131
Comments
Bumped into this as well. This should fix it: peteut@1f7e179 . |
Hitting this issue aswell. |
wwade
pushed a commit
to wwade/sse
that referenced
this issue
Jan 24, 2023
If we hit a connection error in any of the ..WithContext functions, we end up blocked in the backoff.RetryNotify loop. This loop can use a context, but it needs to be bound to the BackOff provided when RetryNotify is called. Added a test case `TestSubscribeWithContextAbortRetrier` to demonstrate the problem and verify the fix. Fixes r3labs#131.
wwade
pushed a commit
to wwade/sse
that referenced
this issue
Jan 24, 2023
If we hit a connection error in any of the ..WithContext functions, we end up blocked in the backoff.RetryNotify loop. This loop can use a context, but it needs to be bound to the BackOff provided when RetryNotify is called. Added a test case `TestSubscribeWithContextAbortRetrier` to demonstrate the problem and verify the fix. Fixes r3labs#131.
Any ETA on this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
SubscribeWithContext
andSubscribeChanWithContext
should respect if the passed context got cancelled and by definition return that error. Am i wrong?The text was updated successfully, but these errors were encountered: