Cache the error from the last asynchronous reconciliation #391
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of your changes
Related issue: crossplane-contrib/provider-upjet-aws#1164, crossplane-contrib/provider-upjet-azure#684
This PR proposes a set of changes to:
These changes result in the
Synced
status condition to being set toFalse
when the asynchronously executing reconciliation operation encounters an error. Previously, we used to set aLastAsyncOperation
to signal an error that the last asynchronous operation has encountered but we did not set theSynced
status condition toFalse
, which is a violation of the XRM contract.The same issue exists also for the Terraform CLI-based asynchronous external client but we will address that client in a follow-up PR.
I have:
make reviewable
to ensure this PR is ready for review.backport release-x.y
labels to auto-backport this PR if necessary.How has this code been tested
Tested by updating a
Policy.iam
resource with an invalid policy document as described in crossplane-contrib/provider-upjet-aws#1164. Without the proposed changes here, here's a log of the registeredSynced
status condition values after each reconciliation when a bad policy document is specified. Initially, the policy document is a valid one:Here, the first reconciliation is done on a valid document, and the remaining ones are done on an invalid document (the ones on invalid document are exponentially backed-off).
And with the proposed changes, here are the logs for the same scenario:
So, after the asynchronous reconciliation encounters an error, the
Synced
condition is set toFalse
and it's stable, i.e., it does not oscillate between theTrue
&False
states as long as the desired policy document stays invalid (with a bad syntax). When it's set to a valid document, theSynced
condition is stably set toTrue
(stays at the stateTrue
).And here's the full
status.conditions
in error state:A test similar to the one described above was conducted for SecurityGroupIngressRule resource, using the example manifest.