Skip to content

Conversation

@sfleen
Copy link
Contributor

@sfleen sfleen commented Nov 6, 2025

Companion to #14682

The previous retry logic relied on direct metadata API calls in cases where the informer cache hadn't updated when injecting a pod.

This updates the retry logic to force a refresh of the informer cache instead of going to the metadata API.

Companion to #14682

The previous retry logic relied on direct metadata API calls in cases where the informer cache hadn't updated when injecting a pod.

This updates the retry logic to force a refresh of the informer cache instead of going to the metadata API.

Signed-off-by: Scott Fleener <[email protected]>
@sfleen sfleen force-pushed the sfleen/root-owner-retry-update branch from a852055 to 7321226 Compare November 6, 2025 16:40
// which leaves a small possibility that the informer cache hasn't
// picked up the new resource yet. If that is the case, we force an
// informer resync to pick up the new resource.
api.Sync(nil)
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't force an informer resync. This simply starts each informer (they are already started at this point) and waits for them to have their initial data. I believe that this is a no-op at this point and doesn't guarantee that the object we want will be in cache.

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.

3 participants