Correctly handle empty watch event cache

[liggitt]

Fixes #49956

Introduced by ada6023 which did not adjust the oldest available resourceVersion for an empty watch event cache.

Exposed by 74b9ba3, which allowed controllers to get list results from etcd before the watch cache is ready (normally they list with resourceVersion=0 which serves the list request from the watch cache, blocking until it is ready)

When the watch cache had an empty cache of watch events, it currently allows establishing a watch as if it can deliver a watch event for its currently synced resourceVersion. This results in an off-by-one error which can result in a missed watch event.

Scenario:

bob:

1. creates object at resourceVersion=11

sally:

1. does a list API request, gets a list resourceVersion of 10 (just before bob creates the object)
2. starts watch handled by watch cache at resourceVersion=10

Watch cache:

1. initial list gets resourceVersion=11, including the item created by bob
2. when determining the initial watch events to send to sally's watch, there are no watch events in the cache, so no initial watch events are sent.
3. the cache listerwatcher watches etcd starting at resourceVersion=11, so future events are fed into the event cache and to sally's watch

The watch cache should have dropped sally's watch from resourceVersion=10 with a "gone" error, since it can't deliver the watch event for resourceVersion=11. This would force sally to relist (where she would get a list at resourceVersion=11) and rewatch (from resourceVersion=11)

This particularly affects tests that create CRD/TPRs and establish watches on the new types as the storage layer's watch cache is also populating for that type.

Fixed a bug in the API server watch cache, which could cause a missing watch event immediately after cache initialization.

[liggitt]

@kubernetes/sig-api-machinery-bugs

[smarterclayton]

I follow all the logic

[liggitt]

/test pull-kubernetes-verify

[liggitt]

on master, TestClientGoCustomResourceExample fails 20% of the time locally for me.

with this change, I cannot get it to fail (ran it ~150 times in a row before stopping the loop)

[liggitt]

@ironcladlou this fix also resolves most of the timeout issues I was seeing with other integration tests depending on watch on CRD objects (like TestMixedRelationships)

[wojtek-t]

@liggitt - thanks a lot for this fix

/lgtm

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, wojtek-t

Associated issue: 49956

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• staging/src/k8s.io/apiserver/pkg/storage/OWNERS [liggitt,wojtek-t]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[wojtek-t]

/retest

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-ci-robot]

@liggitt: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-kubernetes-e2e-kops-aws	0df769f	link	/test pull-kubernetes-e2e-kops-aws

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 49992, 48861, 49267, 49356, 49886)

[ironcladlou]

Awesome, thanks.

[ironcladlou]

cc @caesarxuchao

[k8s-cherrypick-bot]

Commit found in the "release-1.7" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked.