fix: invalidate cluster cache after sync operations #745
Conversation
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #745 +/- ##
==========================================
- Coverage 54.26% 47.75% -6.51%
==========================================
Files 64 64
Lines 6164 6627 +463
==========================================
- Hits 3345 3165 -180
- Misses 2549 3203 +654
+ Partials 270 259 -11 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
pkg/engine/engine.go
Outdated
| // Invalidate the entire cache to ensure consistency | ||
| e.cache.Invalidate() |
There was a problem hiding this comment.
Invalidating the entire cache during a sync operation seems heavy... iirc this forces a re-list of everything on the destination cluster, which is slow and expensive. Is there something more narrow we could do?
There was a problem hiding this comment.
Yeah, i was thinking that we can only invalidate cache for resources which were modified. Need to check if this is possible and what the possible side-effects are
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
|
There have been several times after a sync that the diff shows the live resource before the sync, causing incorrect diffs. This change will ensure if there is a sync with a valid task (non no-op) then we invalidate the cache. We only invalidate cache for resources that were modified to save on operational cost
This is guaranteeing fresh data for subsequent diff calculations
This could also help/fix this issue with CRDs argoproj/argo-cd#20458
as previously after a CRD schema changes and is synced, we run into a diff error because diff is using stale schema