LBListener goes unsynced after upgrading provider-aws-elbv2 across v1.23.2: "defaultAction is a required parameter"

Last updated: July 29, 2026

Issue

  • After upgrading provider-aws-elbv2 / upbound-provider-family-aws across v1.23.2 (e.g. v1.23.0 → v1.23.15), pre-existing LBListener managed resources go unsynced

  • The apply is rejected with a misleading validation error:

LBListener.elbv2.aws.upbound.io "<name>" is invalid:
spec: Invalid value: spec.forProvider.defaultAction is a required parameter

  • defaultAction is actually present in both the composition output and the stored MR

  • The underlying AWS NLB / listener stays healthy — this is a control-plane reconciliation failure only

  • Blocks any change while environments run mixed provider versions

  • Only affects LBListener resources created before the upgrade; freshly created resources on the new version are fine

Environment

  • Crossplane / UXP (also reproduces on upstream Crossplane)

  • provider-aws-elbv2 / upbound-provider-family-aws — schema change introduced in v1.23.2

  • LBListener resources with a defaultAction entry, created on a version older than v1.23.2

Resolution

  • Workaround: explicitly set index: "default" on each defaultAction entry in your composition

  • Guard it so it is only added when the provider version is v1.23.2 or later

  • Example:

spec:
  forProvider:
    defaultAction:
    - index: default
      type: forward
      targetGroupArnRef:
        name: <target-group-name>

  • After applying, the affected LBListener resources return to Synced

  • Validated: confirmed to bring all affected LBListener resources back in sync

Cause

  • In v1.23.2, spec.forProvider.defaultAction changed from an atomic list to a Kubernetes map-type list keyed on a new index field (x-kubernetes-list-map-keys: [index], default value default)

  • This was a server-side-apply (SSA) merge-strategy fix for atomic-list merge conflicts when multiple controllers manage the list

  • Kubernetes does not migrate existing managedFields ownership from atomic to granular topology; resources created before the change keep a stale atomic ownership entry that conflicts with the new map schema

  • Without the index identity key, SSA cannot locate the list item to patch it, which surfaces as the misleading "defaultAction is a required parameter" error

  • Freshly created resources on the new version receive the index field and are unaffected