The TestGetCacheBypass requires watch cache to be initialized after
which it will want backend to return errors to check what requests are
cached and which are not.
The watch cache is marked as ready after a list succeeds, but before a watch request is executed.
If watch request fail it will immidietly flip back to unready.
Injecting error after watch cache was ready didn't guarantee that watch
request started, sometimes causing watch to be called after and fail.
This immidietly caused the watch cache to be again unready for the rest
of the test.
The fix is just to separate failure injection for List and Watch
responses.
Kubernetes-commit: 70e05132645d5c49cf0ac61a3ae8869dc60f0bde
This doesn't matter for shouldDelegateList, but matters when picking
source of RV. RV from continue takes precedence.
Kubernetes-commit: 7da942ca7486310893d4f11f3af062957f953555
Noticed that cache might not nesseserly observe the write causing test
to flake. Fixed that changing the logic to require LessOrEqual of
writeRV instead of equal to writeRV. Also added comments explaining
edge cases.
Kubernetes-commit: 86169a7a1e09c120cadafc0213afbf9630f0d8af
When ResourceVersionMatch is set to NotOlderThan, there is no need to handle continue or resourceVersion="".
The validation in apimachinery will not pass and return:
* "resourceVersionMatch is forbidden when continue is provided"
* "resourceVersionMatch is forbidden unless resourceVersion is provided"
Kubernetes-commit: a0cc02e264ead76dfb0ae75a505e4d2e54219def
We cannot use limit as it would apply it before filtering, which is done
in cacher. Limit is not currently used, but let's remove it to be save,
until filtering is implemented in store.
Kubernetes-commit: 168c338f7cb44a08f3d1a7e1d0e72cac241e9a29
retryAfterSeconds is based on the time elapsed since the state (ready, unready) was last changed.
Kubernetes-commit: 04f0bd4e83bbc0a24b8a924333544be86b252c97