Expose the ResourceUpToDate status from Observe in the MR status/conditions

[bobh66]

What problem are you facing?

When resources are in Observe-only mode there is no way to know if the resource matches the remote resource, and if adding the Update policy would trigger any updates in the remote.

How could Crossplane help solve your problem?

The Observe method returns a ResourceUpToDate flag that would determine whether the Update method gets called if it was allowed, so it would be very useful to expose the value of this flag on the Managed Resource status, possibly as a Condition.

[bobh66]

Some thoughts on the reasons that an UpToDate condition could be true, false or unknown:

• the resource could be in Observe-only mode and the ResourceUpToDate indicator is false (Status: false)
• the resource could be in Observe-only mode and the ResourceUpToDate indicator is true (Status: true)
• the resource could be in non-Observe-only mode and the ResourceUpToDate indicator is true (Update is allowed but not called) (Status: true)
• the resource could be in non-Observe-only mode and the ResourceUpToDate indicator is false, Update is allowed but returned an error (Status: false)
• Reconciliation could be paused so the status is unknown (Status: unknown)

The variety of possible causes makes me think it's more valuable to have this as a condition as opposed to just returning the value of the ResourceUpToDate attribute in the status.

[jcogilvie]

potential caveat: at least in the aws provider, crossplane wants to tag stuff with default tags out of the box. ref

so during an import, wouldn't this be exclusively true for every resource in observe mode, unless the "up to date" flag somehow omits those?

edit: i ran this through claude, and its assessment was that ResourceUpToDate will have the behavior i want--omitting those tags--because observe skips the initialize phase where the mandatory tags are added, but then it suffers from a semantic flaw where the first thing it does when you give it update permissions is go write down those tags, which is technically an update. so i think we'd need some pretty big bold text about that.

[bobh66]

It looks like upjet sets the tags in the Initialize() method so they should be there in the comparison. I am curious how we would set those tags on the external resource when we're in Observe-only mode since we should not be calling the Update method.

[jcogilvie]

oh, no, we definitely don't set them on Observed (only) resources in the cloud; that would definitely break the permission model. my concern was that the provider wants to set them, and that this could constitute a desired update that would cause ResourceUpToDate to always be false for newly-observed resources. but based on my edit above (if correct), it seems like for observe-only resources we skip the init phase where those tags are added to desired state, so this wouldn't be an issue, but it does raise that other issue of not notifying folks that the tags are about to change.

[bobh66]

Yeah that could be a real problem - if the observe-only resources are never "up to date" because they don't have the crossplane tags it makes import a lot harder. I'll run some tests to see what it's doing today.

[bobh66]

I created a test VPC directly in AWS that doesn't have any crossplane tags and then I created an observe-only VPC.ec2 MR with the VPC ID as the external-name and applied it.

The logs for that MR show:

2026-03-08T15:10:49Z	DEBUG	provider-aws	Reconciling	{"controller": "managed/ec2.aws.upbound.io/v1beta1, kind=vpc", "request": {"name":"testvpc"}}
2026-03-08T15:10:49Z	DEBUG	provider-aws	Connecting to the service provider	{"uid": "2d258f39-0e0e-4f81-bcab-ef77e109d077", "name": "testvpc", "namespace": "", "gvk": "ec2.aws.upbound.io/v1beta1, Kind=VPC"}
2026-03-08T15:10:49Z	DEBUG	provider-aws	Observing the external resource	{"uid": "2d258f39-0e0e-4f81-bcab-ef77e109d077", "name": "testvpc", "namespace": "", "gvk": "ec2.aws.upbound.io/v1beta1, Kind=VPC"}
2026-03-08T15:10:50Z	DEBUG	provider-aws	External resource is up to date	{"controller": "managed/ec2.aws.upbound.io/v1beta1, kind=vpc", "request": {"name":"testvpc"}, "uid": "2d258f39-0e0e-4f81-bcab-ef77e109d077", "version": "14947090", "external-name": "vpc-myexternalvpc", "requeue-after": "2026-03-08T15:15:58Z"}

which would seem to indicate that the ResourceUpToDate flag is true even when the crossplane tags don't exist, which is exactly what we want.

It might also be useful to include the observation.Diff in the status condition message so all of the relevant information is available in one place in the condition.

[jcogilvie]

It might also be useful to include the observation.Diff in the status condition message so all of the relevant information is available in one place in the condition.

Supremely useful, yes.

[bobh66]

This got more complicated after the API refactor and now needs to be split across both this repo and the crossplane core repo for the condition API change. I'll open that PR and hopefully get it merged and then push the PR for this side.

[bobh66]

Should the Composite reconciler reflect the aggregated UpToDate status of it's child resources?  If at least one child resource has UpToDate == False then maybe the composite should also be UpToDate == False?  Originally I was thinking that UpToDate wouldn't apply to composite resources, but maybe it should? If only one child resource is false then it could reflect the status of that resource, but if multiple resources are false we would need another condition reason that only applies to composite resources, like ChildrenNotUpToDate or something