-
Notifications
You must be signed in to change notification settings - Fork 420
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
Only schedule a close if the ping was actually sent #1626
Conversation
|
1 similar comment
|
@marhas -- thanks for the PR. I'll need you to fix up your CLA before I can review this though. |
Hello George,
I believe I already have:

Is there anything else I need to do?
Thanks,
Marcel
… On 5 Jul 2023, at 14:32, George Barnett ***@***.***> wrote:
@marhas <https://github.com/marhas> -- thanks for the PR. I'll need you to fix up your CLA before I can review this though.
—
Reply to this email directly, view it on GitHub <#1626 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQM23QBURZJMZW67XITAQTXOVNEJANCNFSM6AAAAAAZ6WNX4U>.
You are receiving this because you were mentioned.
|
Oh sorry my mistake; the bot usually updates the comment when the issue is resolved but I see the check has passed. |
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.
Thanks for fixing this Marcel!
Thanks for reviewing and merging it so quickly! |
Co-authored-by: George Barnett <[email protected]>
Co-authored-by: George Barnett <[email protected]>
If an outbound ping is blocked, I believe we should not schedule a close of the connection.
For me this caused intermittent issues with "unavailable (14): Transport became inactive" when calling the same streaming endpoint repeatedly. The last outbound ping would be blocked by shouldBlockPing because the stream had closed, but a closeConnection call is still scheduled, potentially closing the connection of a consecutive call when fired.