Description (en formato Wiki markup para Jira):

Description of problem

In support/util/imagemetadata.go, the function getMirrorFromICSPOrIDMS calls context.WithTimeout inside a for loop (line 545) and uses defer cancel() to release the context. However, defer

only executes when the enclosing function returns, not at the end of each loop iteration. This means that for every mirror iterated, a new context is created but never cancelled until the function exits, causing

context accumulation and potential resource leaks proportional to the number of mirrors configured.

Version-Release number of selected component (if applicable)

4.20, 4.21 (present in main branch as well)

How reproducible

Always

Steps to Reproduce

1. Configure multiple ImageContentSourcePolicies (ICSP) or ImageDigestMirrorSets (IDMS) with several mirror entries
2. Trigger image metadata resolution that calls getMirrorFromICSPOrIDMS
3. Observe that each loop iteration creates a new context via context.WithTimeout but defers the cancel

Actual results

The cancel() function is deferred inside the loop, so it accumulates for each mirror entry. All cancel functions are only called when the outer function returns, leading to unnecessary context and resource accumulation.

  // Cache miss - verify mirror availability with 15s timeout
  verifyCtx, cancel := context.WithTimeout(ctx, 15*time.Second)
  defer cancel()  // BUG: this accumulates, not called until function returns

  if _, _, _, err = getMetadata(verifyCtx, mirrorURL, pullSecret); err == nil {
  

Expected results

The cancel() function should be called immediately after the getMetadata call, or the code should be wrapped in an inline function so that defer cancel() runs at each iteration.

Additional info

Found by @csrwng during review of backport PR:

• PR comment: https://github.com/openshift/hypershift/pull/7842#discussion_r2874921383
• Backport PR: https://github.com/openshift/hypershift/pull/7842
• Original PR: https://github.com/openshift/hypershift/pull/7184
• File: support/util/imagemetadata.go, lines 545-547