Skip to content
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

quic: Assert that there are streams available in EnvoyQuicClientSession::OnCanCreateNewOutgoingStream #18786

Closed

Conversation

RyanTheOptimist
Copy link
Contributor

@RyanTheOptimist RyanTheOptimist commented Oct 26, 2021

quic: Assert that there are streams available in EnvoyQuicClientSession::OnCanCreateNewOutgoingStream now that QUICHE has been fixed.

Signed-off-by: Ryan Hamilton [email protected]

Risk Level: Low
Testing: Existing
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

@RyanTheOptimist
Copy link
Contributor Author

/assign @alyssawilk

@RyanTheOptimist RyanTheOptimist marked this pull request as draft October 26, 2021 21:56
@alyssawilk
Copy link
Contributor

Did you try the 2k local runs? Or is this after an upstream fix?
/wait

Signed-off-by: Ryan Hamilton <[email protected]>
@RyanTheOptimist
Copy link
Contributor Author

Did you try the 2k local runs? Or is this after an upstream fix?

Sorry, I converted this to a draft just after I sent it to you because I realized that the ASSERT I changed wasn't where I expected it to be and needed to dig deeper. Ah well :) In any case, back in #18694 we discussed an ASSERT in OnCanCreateNewOutgoingStream() when we compute the available streams. That method should only be called when there ARE available streams. But then that particular line got factored out into a streamsAvailable() helper method. It seems totally fair to call that method when there are no available streams, so the initial change in this PR is not right. That being said, it does seem to pass locally, though that confuses me. In any case, I've tweaked this PR to add an ASSERT back to OnCanCreateNewOutgoingStream(). I verified that this also passed 2000 runs, but applying this fix without the upstream QUICHE fix fails. So I think it's good to go now. Sorry for the false start!

(Is there a way to un-assign a PR?)

@RyanTheOptimist RyanTheOptimist changed the title quic: Tighten an assert in EnvoyQuicClientSession::streamsAvailable quic: Assert that there are streams available in EnvoyQuicClientSession::OnCanCreateNewOutgoingStream Oct 27, 2021
@RyanTheOptimist RyanTheOptimist marked this pull request as ready for review October 27, 2021 17:21
@RyanTheOptimist
Copy link
Contributor Author

Oh interesting. In #18775 we're calling OnCanCreateNewOutgoingStream() even when there are no new streams available. In that case, maybe this current PR is a non-goal?

@@ -101,6 +101,7 @@ void EnvoyQuicClientSession::OnCanCreateNewOutgoingStream(bool unidirectional) {
return;
}
uint32_t streams_available = streamsAvailable();
ASSERT(streams_available > 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I don't think we want this because it's not going to play well with my PR in progress, where we artificially call OnCanCreate... to update the conn pool when we complete handshake even if there's no streams. I alternately we can change that PR to manually onMaxStreamsChanged but I mildly prefer just not adding this assert

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I came to that conclusion as well in my previous comment. C'est la vie :) I'll close this out.

Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/wait

@RyanTheOptimist RyanTheOptimist deleted the streamsAvailable branch October 28, 2021 15:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants