[Bug]: LastAsyncOperation is failed, but resource has been marked as ready

[hannupiki-eficode]

Is there an existing issue for this?

• I have searched the existing issues

Affected Resource(s)

At least these two:

• network.azure.upbound.io/v1beta1 - ApplicationGateway
• managedidentity.azure.upbound.io/v1beta1 - FederatedIdentityCredential

Resource MRs required to reproduce the bug

No response

Steps to Reproduce

1. Create ApplicationGateway with proper configuration that does deploy it successfully
2. Add spec.forProvider.authenticationCertificate object with invalid name
3. Observe LastAsyncOperation and verify that resource status is still ready

If you use nested compositions, deploy ApplicationGateway into child composition and verify that also parent composition is showing everything as ready.

What happened?

Expected: Resource and compositions would be reporting resource as failed in all levels (parent and child composition and resource itself).
Observed: Resource, its composition and parent composition are showing everything as ready. Resource's LastActivityOperation is showing an error that prevents applying the change and therefor resource isn't matching the state that have been written into Git and pushed into cluster from there.

In these screenshots you see obvious failure that is rightfully failing, but also how these resources do look like with common ways of checking their status:

Output from kubectl get managed

Parent composition

Actual ApplicationGateway resource

Relevant Error Output Snippet

No response

Crossplane Version

1.15.1

Provider Version

xpkg.upbound.io/upbound/provider-azure-network:v1.0.0, xpkg.upbound.io/upbound/provider-azure-managedidentity:v1.0.0

Kubernetes Version

v1.27.7

Kubernetes Distribution

AKS

Additional Info

No response

[erhancagirici]

@hannupiki-eficode thanks for reporting. This issue is similar to crossplane-contrib/provider-upjet-aws#1164 . The cause is explained at crossplane-contrib/provider-upjet-aws#1164 (comment) and we will follow up there.

[turkenf]

I'm closing this issue because we introduced a fix for the issue in provider v1.1.0