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

Close dependent http responses before closing api context #1109

Merged
merged 2 commits into from
Apr 8, 2024

Conversation

asteven
Copy link
Contributor

@asteven asteven commented Mar 18, 2024

Pending aiohttp.ClientResponse instances depend on the aiohttp session stored within a APIContext.

If the APIContext is closed, all responses that depend on in just hang forever or until a configured timeout expires.

Keeping track of aiohttp.ClientResponses and properly closing them if the APIContext itself is closed prevents this from happening. The pending requests are automatically retried instead of left dangling.

We've been using this patch since 10 months in production and have never again seen the errors related to handlers not firing anymore after re-authentication.

closes: #1036

Signed-off-by: Steven Armstrong <steven@armstrong.cc>
…ses related to a session

Signed-off-by: Steven Armstrong <steven@armstrong.cc>
@asteven asteven requested a review from nolar as a code owner March 18, 2024 16:21
@ron-matsliah
Copy link

Hi @nolar, can you please check it out?
It's causing our service to get stuck

Copy link
Owner

@nolar nolar left a comment

Choose a reason for hiding this comment

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

Note for self & for future code archaeologists later:

At a first glance, this problem should be already solved by closing the responses in the async with response: … statements in all the get/post/patch methods in kopf/_cogs/clients/api.py. The only exception is streaming, but even there it is closed in the routine the same way; the only difference is that a routine itself is wrapped with a little magic to run in a background.

However, there is another chain of events described in #1036 (comment), which involves catching HTTP 401 from the server and initiating the re-authentication, which implicitly closes the old session BUT without closing the old responses. As such, they get stuck and do not reconnect util kicked/timed out.

This PR introduces a force-stop for those pending connections (likely streaming/watching responses) that are bound to the old 401'ed session.

@nolar nolar enabled auto-merge April 8, 2024 12:38
@nolar nolar merged commit 9243c8f into nolar:main Apr 8, 2024
28 checks passed
@nolar
Copy link
Owner

nolar commented Apr 8, 2024

Thanks for the PR. Released as 1.37.2.

@asteven asteven deleted the close_responses branch April 8, 2024 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

kopf does not fire handlers after re-authentication
4 participants