-
Notifications
You must be signed in to change notification settings - Fork 940
Fix for b/74749605: Cancel pending backoff operations when closing streams. #564
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -316,6 +316,9 @@ export abstract class PersistentStream< | |
|
||
this.cancelIdleCheck(); | ||
|
||
// Ensure we don't leave a pending backoff operation queued. | ||
this.backoff.cancel(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's a little weird that cancelling the idle and backoff timers look different. Is there any way to make these uniform? I suppose this happens because the backoff timer is held within the backoff object but the idle timer is held directly? I think this may be non-actionable, but mentioning it anyway. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. acknowledged. |
||
|
||
if (finalState !== PersistentStreamState.Error) { | ||
// If this is an intentional close ensure we don't delay our next connection attempt. | ||
this.backoff.reset(); | ||
|
@@ -461,10 +464,10 @@ export abstract class PersistentStream< | |
this.state = PersistentStreamState.Backoff; | ||
|
||
this.backoff.backoffAndRun(async () => { | ||
if (this.state === PersistentStreamState.Stopped) { | ||
// Stream can be stopped while waiting for backoff to complete. | ||
return; | ||
} | ||
assert( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Man am I gun-shy about this assertion. I'm somewhat in favor of just leaving the old behavior in place to keep this consistent with the other callbacks. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah... I am torn between being as strict as possible with our state transitions vs being defensive. I mostly changed it to an assert, since as-is it's basically dead code. I put it back though and just tweaked the comment. |
||
this.state === PersistentStreamState.Backoff, | ||
'Backoff should have been canceled if we left the Backoff state.' | ||
); | ||
|
||
this.state = PersistentStreamState.Initial; | ||
this.start(listener); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment can move above the idle cancel and cover both:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hrm. I had trouble creating a unified comment that I didn't feel was overly general or misleading, so instead I just commented both of them separately.
FWIW- the idle timer will only be active if the stream is currently connected when close() is called, and the backoff timer will only be active if the stream is not currently connected when close() is called.