Skip to content

[release-0.33] Return NotFound to WatchList clients when a shard does not serve the resource - #4547

Merged
kcp-ci-bot merged 1 commit into
kcp-dev:release-0.33from
mjudeikis-bot:fix-watchlist-notfound-0.33
Nov 4, 2026
Merged

kcp-ci-bot merged 1 commit into
kcp-dev:release-0.33from
mjudeikis-bot:fix-watchlist-notfound-0.33

Conversation

@mjudeikis-bot

Copy link
Copy Markdown

Summary

Backport of #4384 to release-0.33, superseding #4546. Same change as #4546, with the one fix it needed: in TestWatchNotFoundOnShard, newStorage returns two values on release-0.33 (main returns three), so the call is now storage, _ := newStorage(...). #4546 failed to compile its test package, which is what broke pull-kcp-test-unit and pull-kcp-lint.

Requested in #4546 (comment)

Conflicts: none in the cherry-pick itself; only the test-helper signature difference above.

Tested

  • go vet ./pkg/forwardingregistry/ in the virtual-workspace-framework module: clean
  • go test -race ./pkg/forwardingregistry/: passes
  • golangci-lint run ./... in the virtual-workspace-framework module (repo config): 0 issues
Return NotFound to WatchList clients when a shard does not serve the resource

…resource

A watch for a resource that is not served on this shard is answered with an
empty watch that yields no events and stays open, so that a wildcard consumer
aggregating across shards is not wedged by a shard that simply holds none of
these objects.

A WatchList client cannot use such a stream. It treats the watch as its initial
list and waits for the server to close that list with an "initial-events-end"
bookmark before it considers its store synced. An empty watch sends no such
bookmark, and never errors either, so nothing makes the client relist — the
comment's "objects that later appear on this shard are picked up on the next
relist" never happens, because there is no next relist. The client waits
forever:

  reflector.go:327: awaiting required bookmark event for initial events stream,
  no events received for 10.004121875s

That is reachable in a normal deployment. A controller consuming an APIExport
through its virtual workspace starts before any workspace has bound the export,
so the endpoint slice is still empty; when the first binding appears, the
controller connects and establishes a watch for a resource this shard does not
serve yet. Its informers never sync and it never reconciles anything, with no
error anywhere to explain it.

Surface the NotFound to those clients instead: they retry, and pick the
resource up once the shard serves it. Ordinary watches keep the empty watch and
the behaviour that was added for them.

An alternative would be for the empty watch to emit the initial-events-end
bookmark itself, which would let a WatchList client sync against a shard that
holds nothing. That needs a resourceVersion to report as synced-at, and I did
not want to invent one; if there is a right value to use here, that is the
better fix.

Signed-off-by: Waldemar Kindler <waldemar.kindler@think-ahead.tech>
(cherry picked from commit e99a021)
Signed-off-by: mjudeikis-bot <263128906+mjudeikis-bot@users.noreply.github.com>
@kcp-ci-bot kcp-ci-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has signed the DCO. labels Nov 4, 2026
@kcp-ci-bot kcp-ci-bot added do-not-merge/needs-kind Indicates a PR lacks a `kind/foo` label and requires one. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Nov 4, 2026
@kcp-ci-bot

Copy link
Copy Markdown
Contributor

Hi @mjudeikis-bot. Thanks for your PR.

I'm waiting for a kcp-dev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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-sigs/prow repository.

@mjudeikis

Copy link
Copy Markdown
Contributor

/ok-to-test

@kcp-ci-bot kcp-ci-bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Nov 4, 2026

@ntnn ntnn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@kcp-ci-bot kcp-ci-bot added the lgtm Indicates that a PR is ready to be merged. label Nov 4, 2026
@kcp-ci-bot

Copy link
Copy Markdown
Contributor

LGTM label has been added.

DetailsGit tree hash: 62590d427779be8d3579e15351283e4d12974074

@kcp-ci-bot

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ntnn

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kcp-ci-bot kcp-ci-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 4, 2026
@ntnn

ntnn commented Nov 4, 2026

Copy link
Copy Markdown
Member

/kind bug

@kcp-ci-bot kcp-ci-bot added kind/bug Categorizes issue or PR as related to a bug. and removed do-not-merge/needs-kind Indicates a PR lacks a `kind/foo` label and requires one. labels Nov 4, 2026
@kcp-ci-bot
kcp-ci-bot merged commit 977a306 into kcp-dev:release-0.33 Nov 4, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has signed the DCO. kind/bug Categorizes issue or PR as related to a bug. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants