Cache https.Agent and Dispatcher per cluster/user pair to fix FD leaks on Watch reconnection#2904
Draft
Copilot wants to merge 3 commits into
Draft
Cache https.Agent and Dispatcher per cluster/user pair to fix FD leaks on Watch reconnection#2904Copilot wants to merge 3 commits into
Copilot wants to merge 3 commits into
Conversation
|
…ubeConfig Fixes socket/FD leaks caused by creating a new https.Agent on every Watch reconnection or API call. - Add `agentCache` (Map keyed by "clusterName::userName") to reuse agent instances across repeated calls with the same cluster/user. - Add `dispatcherCache` (same key) to reuse undici Dispatcher instances across repeated applySecurityAuthentication() calls. - Add private `getAgentCacheKey()` helper that builds the key from the current cluster name and user name — consistent with the comment from @brendandburns about keying off the user/cluster tuple. - Add four new tests in config_test.ts verifying same-instance reuse and distinct instances for different cluster/user combinations.
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Copilot The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Copilot
AI
changed the title
[WIP] Fix socket and FD leaks in KubeConfig.createAgent()
Cache https.Agent and Dispatcher per cluster/user pair to fix FD leaks on Watch reconnection
Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
KubeConfig.createAgent()andcreateDispatcher()unconditionally construct a new instance on every call. WithWatch's reconnect pattern, this leaks a new socket pool each cycle — orphaned agents are not promptly GC'd due to reference chains throughnode-fetchresponse body streams, causing steady FD growth and eventualEMFILE.Changes
src/config.tsagentCache: Map<string, Agent>anddispatcherCache: Map<string, Dispatcher | undefined>toKubeConfig, keyed by"clusterName::userName"(the tuple that uniquely determines TLS config and auth)createAgent()andcreateDispatcher()now return a cached instance on subsequent calls for the same cluster/user pair, constructing only on first usegetAgentCacheKey(cluster)helpersrc/config_test.tsBehavior
The cache is keyed by cluster+user names rather than a single global entry, so multi-cluster configs that switch context get the correct per-endpoint agent.