darn, from https://github.com/crossplane/crossplane/actions/runs/11797053040/job/32860259762?pr=6090, it looks like the same --- FAIL: TestPropagateFieldsRemovalToXRAfterUpgrade/TestPropagateFieldsRemovalToXRAfterUpgrade/FieldsRemovalPropagatedToXR is still happening with these changes 😞

@negz mentioned a theory to me yesterday that looks similar to what I think you're trying to do with these changes. To describe it explicitly here, we think there is a race where we are possibly getting to UpdateClaim before the upgrade of crossplane to EnableSSAClaims is actually finished. If that happens, then it'd be possible for the claim to be updated with new values, but removals never get synced to the XR because we're not running with SSA yet.

Then when Crossplane comes up with the upgrade to enable SSA, it's too late and the XR will stay stuck that way forever.

You seem to be attacking that very scenario by waiting for the DeploymentProgressing condition with NewReplicaSetAvailable reason, but is it possible that we could get an immediate false positive on that condition that is still lingering from the initial install of Crossplane? 🤔 If that could happen, this this check would exit very quickly and move onto UpdateClaim possibly before Crossplane is upgraded and running with SSA enabled.

Another idea @negz had instead would be to explicitly check that the Crossplane deployment has the feature flag we care about. Is the Crossplane deployment running but also with --enable-ssa-claims? I'm going to play around with that locally and see if I get good results for this test 🙏

edit: clarified race condition consequences

Crossplane does not currently have enough maintainers to address every issue and pull request. This pull request has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Adding a comment starting with /fresh will mark this PR as not stale.