fix: reset TargetForConfig condition on no-op reconcile#464
Open
steiler wants to merge 2 commits into
Open
Conversation
When a target briefly drops and recovers but no intent hash changes, buildIntentInputs returns hasChanged=false and the reconciler returned early without calling SetConfigsTargetConditionForTarget. Any stale TargetForConfig=Failed condition written during the outage was never cleared, leaving all Config CRs permanently at Ready=False. Mirror the main-branch behaviour: always call SetConfigsTargetConditionForTarget(TargetForConfigReady) at the end of every successful reconcile, even when no transaction was needed. Fixes 22-Srl-Update-Replace CI failures where srl3 briefly lost its dsctx at 07:14:41, setting configs to Ready=False, which were never restored because subsequent reconciles detected no hash change and skipped the condition-reset call. Co-authored-by: Cursor <cursoragent@cursor.com>
c299691 to
1e9e23c
Compare
…cret re-creation When a referenced secret is deleted, the configresolver sets Resolver=False and preserves the last-good SensitiveConfig. If the secret is re-created with identical content, detectChange returns noChange=true because all hashes still match — causing the reconciler to exit early without ever clearing the stale failure condition. The Config would remain non-Ready permanently. Fix: before early-exiting on noChange, check whether the current Resolver condition is False. If it is, call handleSuccess to clear it — the secret is clearly available now (hashes matched), so the stored failure is no longer valid. Fixes TC5 in the 04-sensitive integration test suite. Co-authored-by: Cursor <cursoragent@cursor.com>
steiler
added a commit
to sdcio/integration-tests
that referenced
this pull request
Jul 6, 2026
…ow deviation detection The intent was sent to the data-server as revertive (default). The data-server's active sync cycle continuously restores the intended value to the device every ~5 seconds, overwriting any manually injected deviation before the 10-second deviation-manager poll can observe it. As a result, TC4 never saw devs>0. Setting revertive: false disables auto-correction so a gnmic-injected deviation persists long enough to be detected and reported back to Kubernetes. Pairs-with: sdcio/config-server#464 Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
|
If the status is failed we need to retry iso setting condition to true in my view otherwise we might miss out some configs |
Contributor
Author
|
what does that mean? do you want to adjust this PR? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
When a target briefly drops (e.g.
srl3loses itsdsctx) theTargetConfigControllercallsSetConfigsTargetConditionForTarget(TargetForConfigFailed), setting all Configs for that target toReady=False.When the target recovers, the reconciler runs
buildIntentInputs. If no intent hash has changed (no new configs, no secret rotation)hasChanged=falseand the reconciler returned early:SetConfigsTargetConditionForTarget(TargetForConfigReady)is only called after a successful transaction, so the staleFailedcondition was never cleared. Configs stayed atReady=Falsepermanently until the next unrelated change triggered a new transaction.This caused the
22-Srl-Update-Replacesuite in CI run #460 to fail:srl3dropped at07:14:41, no new intents existed to force a transaction, and the setupConfig Check Readytimed out 2 minutes later still seeing['False'].Fix
Mirror the
main-branch behaviour: callSetConfigsTargetConditionForTarget(TargetForConfigReady)in the no-change early-return path so any staleFailedcondition is always cleared when the target is confirmed healthy, even when nothing needs to be transacted.Test plan
sensitiveCI suite —22-Srl-Update-Replaceshould pass11-Sros-Create-Delete,12-Srl-Create-Delete,21-Sros-Update-ReplaceReady=TruePairs-with: sdcio/integration-tests#108
Pairs-with: sdcio/data-server#460