bug: APIBinding with naming conflicts is not automatically fixed when the older/conflicting APIBinding is removed

[ncdc]

Describe the bug

If you create a 2nd APIBinding that conflicts with another valid APIBinding, and then delete the older APIBinding, the 2nd APIBinding is not automatically reprocessed to see if the conflicts are resolved

Steps To Reproduce

1. Create an APIBinding A that binds some GroupResource GR
2. Create another APIBinding B that binds to a different APIExport that also exports GR
3. See that B has NamingConflicts for the BindingUpToDate condition
4. Delete APIBinding A
5. B still has NamingConflicts
6. Perform some modification to B, such as labeling or annotating it
7. B's NamingConflicts are gone and it is now Ready

Expected Behaviour

It would be nice if we reprocess any APIBindings with NamingConflicts (or maybe any that are not Ready, or maybe even all of them) when an APIBinding is deleted (and/or whenever there is an update?)

Additional Context

No response

[hasheddan]

@ncdc I'd love to pick this one up 👍🏻

/assign @hasheddan

[ncdc]

Sweet, thanks!

[hasheddan]

Just hit this in the wild. Example of what the error looks like for posterity:

🤖 (kxp) k get apibindings kubernetes -o yaml -w
apiVersion: apis.kcp.dev/v1alpha1
kind: APIBinding
metadata:
  annotations:
    kcp.dev/cluster: root
    workload.kcp.dev/skip-default-object-creation: "true"
  creationTimestamp: "2022-10-06T12:26:11Z"
  finalizers:
  - apis.kcp.dev/apibinding-finalizer
  generation: 1
  labels:
    claimed.internal.apis.kcp.dev/9dNq1d0MsNtSRlLOXXDBZHy5othGQzTcNDeaOT: LstvmbbzVDDOn90ZbhzSQO5U3DMCf88h1pZ
    internal.apis.kcp.dev/export: 9dNq1d0MsNtSRlLOXXDBZHy5othGQzTcNDeaOT
  name: kubernetes
  resourceVersion: "510"
  uid: 3fb01853-7f15-48e4-b0a7-4b5fab1a6aed
spec:
  reference:
    workspace:
      exportName: kubernetes
      path: root
status:
  boundExport:
    workspace:
      exportName: kubernetes
      path: root
  conditions:
  - lastTransitionTime: "2022-10-06T12:26:11Z"
    status: "True"
    type: Ready
  - lastTransitionTime: "2022-10-06T12:26:21Z"
    message: An internal error occurred with the APIExport
    reason: InternalError
    severity: Error
    status: "False"
    type: APIExportValid
  - lastTransitionTime: "2022-10-06T12:26:21Z"
    message: 'Unable to bind APIs: error checking for naming conflicts for APIBinding
      root|kubernetes: error getting CRDs: apiexport.apis.kcp.dev "root|kxp.apiextensions.crossplane.io"
      not found'
    reason: NamingConflicts
    severity: Error
    status: "False"
    type: BindingUpToDate
  - lastTransitionTime: "2022-10-06T12:26:11Z"
    status: "True"
    type: InitialBindingCompleted
  - lastTransitionTime: "2022-10-06T12:26:11Z"
    status: "True"
    type: PermissionClaimsApplied
  - lastTransitionTime: "2022-10-06T12:26:11Z"
    status: "True"
    type: PermissionClaimsValid
  phase: Bound

[hasheddan]

In the specific case above, there wasn't actually a naming conflict. The APIBinding in question just wasn't ready yet because the APIExport it referenced did not yet exist.

[kcp-ci-bot]

Issues go stale after 90d of inactivity. After a furter 30 days, they will turn rotten. Mark the issue as fresh with /remove-lifecycle stale.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kcp-ci-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[kcp-ci-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

[kcp-ci-bot]

@kcp-ci-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.