feat: add resourceVersion to Freight, Stage, Warehouse list and watch endpoints#6156
feat: add resourceVersion to Freight, Stage, Warehouse list and watch endpoints#6156jessesuen wants to merge 1 commit into
Conversation
✅ Deploy Preview for docs-kargo-io ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #6156 +/- ##
=======================================
Coverage 57.69% 57.69%
=======================================
Files 474 475 +1
Lines 40499 40558 +59
=======================================
+ Hits 23365 23401 +36
- Misses 15739 15758 +19
- Partials 1395 1399 +4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
643eb5a to
a669935
Compare
| // effectiveResourceVersion returns rv if it is a real, non-default Kubernetes | ||
| // resource version (non-empty and non-"0"). Otherwise it computes the maximum | ||
| // resource version from the provided item versions, which serves as a safe | ||
| // lower bound for a subsequent Watch: any event with a higher resource version | ||
| // is guaranteed to be newer than the listed state. | ||
| // | ||
| // Background: the controller-runtime cached client returns "0" for the | ||
| // list-level ResourceVersion, which causes a Kubernetes Watch to replay all | ||
| // existing objects as ADDED events. Using the maximum object-level resource | ||
| // version avoids this replay while still being correct: every modification to | ||
| // a listed object, and every new object created after the list, will have a | ||
| // resource version greater than this value. | ||
| func effectiveResourceVersion(rv string, itemVersions []string) string { |
There was a problem hiding this comment.
This was an interesting discovery during end-to-end testing.
The Kargo API uses the controller-runtimes cached client for list requests. Before this helper, the List call had blindly carried over the resourceVersion from the cached client's List response. But that value was always 0, and so the result had no benefit for UI performance since the subsequent Watch would replay all objects.
This helper allows us to continue using the cached client while benefiting from a smaller payload in the subsequent Watch call by using the max resourceVersion from the cached list. In my testing/research, this works as advertised, but need to proceed cautiously here.
87761a3 to
e817c26
Compare
… endpoints Signed-off-by: Jesse Suen <jesse@akuity.io>
e817c26 to
0a0b864
Compare
Summary
resource_versionto the List response messages for Stages, Warehouses, and Freight (ListStagesResponse,ListWarehousesResponse,QueryFreightResponse), and to the Watch request messages (WatchStagesRequest,WatchWarehousesRequest,WatchFreightRequest).resourceVersionin responses. Because the controller-runtime cached client always returns "0" for the list-level ResourceVersion, a new effectiveResourceVersion helper falls back to max(item.ResourceVersion) across all returned objects when the list-level value is absent or "0". This yields a valid lower-bound resource version without bypassing the cache.resourceVersionparameter and forward it to the underlying Kubernetes Watch call. When provided, Kubernetes sends only events newer than that version, eliminating the full ADDED-event replay that previously occurred on every Watch connection.Motivation
This enables the standard Kubernetes list-then-watch pattern: a client can call a List endpoint, record the returned resourceVersion, then start a Watch from that exact point to receive all subsequent changes without gaps or redundant initial events.
Tests