Skip to content
This repository was archived by the owner on Aug 5, 2026. It is now read-only.

fix(archive): resolve CompositionDefinition via definition-ref labels + unique-kind fallback - #24

Merged
braghettos merged 1 commit into
mainfrom
fix/cd-lookup-definition-ref
Jul 13, 2026
Merged

fix(archive): resolve CompositionDefinition via definition-ref labels + unique-kind fallback#24
braghettos merged 1 commit into
mainfrom
fix/cd-lookup-definition-ref

Conversation

@braghettos

Copy link
Copy Markdown
Collaborator

Problem

searchCompositionDefinition (internal/tools/archive/getter.go) wedges during chart-version bumps: with >1 CompositionDefinition in the cluster it requires an EXACT match between the CD's status chart version and the composition instance's krateo.io/composition-version label. During a bump the CD status moves (e.g. v1-5-12) while the existing instance's label still says v1-5-11 → no match → too many definitions [N] found → reconcile permanently wedged (only a successful reconcile would migrate the label — chicken-and-egg). Observed live on a 29-CD cluster bumping the portal 1.5.11→1.5.12; recovery required rolling back the version.

Fix — ordered fallback chain

  1. Definition-ref labels (authoritative): instances already carry krateo.io/composition-definition-name + -namespace; if present, resolve the CD directly by name+namespace.
  2. Exact version+kind match — previous behavior, unchanged.
  3. Unique-kind last resort: if exactly one CD has status.kind == the instance kind, use it and log a Warn about tolerated version-label skew (unwedges version-bump migration). Zero or >1 → the existing error.

tot==1 fast path unchanged.

Tests

New getter_search_test.go (fake dynamic client, table-driven, 6 cases): ref-labels win under skew+same-kind ambiguity; exact-match regression; stale ref-labels fall through; unique-kind unwedges the observed scenario; ambiguous still errors; single-CD fast path. go build ./... ✓, go test ./internal/tools/archive/... ✓ (the internal/tools/rbac package failure is pre-existing/environmental — spins a real kind cluster, identical on main).

🤖 Generated with Claude Code

… + unique-kind fallback

searchCompositionDefinition resolved the owning CompositionDefinition by
listing ALL CompositionDefinitions and, with more than one present,
requiring an EXACT match between the CD's status.apiVersion version
suffix and the instance's krateo.io/composition-version label (plus
status.kind == instance kind). During a chart-version bump the CD's
status version moves ahead (e.g. v1-5-12) while the existing instance's
label still says v1-5-11: no match -> 'too many definitions [N] found'
-> reconcile permanently wedged, since only a successful reconcile would
migrate the label (chicken-and-egg).

Composition instances already carry authoritative owner-reference
labels (krateo.io/composition-definition-name/-namespace, stamped via
SetCompositionDefinitionLabels) that the matcher ignored. Replace the
match with an ordered fallback chain, preserving current behavior where
it works:

1. definition-ref labels: pick the listed CD matching the instance's
   composition-definition-name + -namespace labels (authoritative,
   survives version bumps); stale labels fall through.
2. exact (chart version == composition-version label) AND
   (status.kind == kind) match, as before.
3. last resort: if EXACTLY ONE CD serves the instance's kind, use it
   and Warn that version-label skew was tolerated -> unwedges
   version-bump migrations. Zero or ambiguous still errors.

The tot==1 fast path (single CD -> Items[0]) is unchanged.

Unit tests (fake dynamic client, table-driven) cover: ref-label match
winning under version skew + same-kind ambiguity, exact-match
regression, stale-ref fallthrough, unique-kind skew tolerance,
ambiguous same-kind error, and the single-CD fast path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@braghettos
braghettos merged commit 57d07b0 into main Jul 13, 2026
3 checks passed
@braghettos
braghettos deleted the fix/cd-lookup-definition-ref branch July 13, 2026 20:10
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant