Skip to content

test(source): add regression coverage for TCPRoute referencing a ListenerSet - #6578

Open
pujitha24 wants to merge 2 commits into
kubernetes-sigs:masterfrom
pujitha24:auto/issue-6557
Open

test(source): add regression coverage for TCPRoute referencing a ListenerSet#6578
pujitha24 wants to merge 2 commits into
kubernetes-sigs:masterfrom
pujitha24:auto/issue-6557

Conversation

@pujitha24

@pujitha24 pujitha24 commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

What this does

Adds TCPRoute+ListenerSet coverage for the gateway-tcproute source.

TestGatewayTCPRouteWithListenerSetParentRef builds a Gateway -> ListenerSet -> TCPRoute (whose parentRef targets the ListenerSet) and asserts the gateway-tcproute source resolves the expected endpoint (app.example.com) when --gateway-listener-sets is enabled — mirroring the existing HTTPRoute + ListenerSet coverage in this file.

Why

Issue #6557 reported that a TCPRoute referencing a ListenerSet failed to resolve while an equivalent HTTPRoute worked. resolveParentRef/routeIsAllowed in source/gateway.go already handle TCPRoute correctly on current HEAD (this test passes without any production-code change), but that path had zero TCPRoute-specific test coverage before this PR.

As pointed out in review, this test is not a regression guard for #6557: nothing here fails without a fix and passes with one, so it can't demonstrate the reported bug ever existed in this code path. The root cause remains unconfirmed — possibly --gateway-listener-sets not being enabled in the reporter's environment (it defaults to false), an informer cache-sync race, RBAC restricting list/watch on ListenerSet, or an interaction specific to running --source=gateway-tcproute and --source=gateway-httproute together that isn't exercised by a single-source unit test. This PR only adds missing coverage for the TCPRoute+ListenerSet path; it does not close or resolve #6557.

Notes

  • Test-only change; no functional code modified.
  • go test ./source/... passes locally.

Relates to #6557

Motivation:
Issue kubernetes-sigs#6557 reports that a TCPRoute referencing a Gateway API
ListenerSet (e.g. an Envoy Gateway ListenerSet) fails to resolve via
--source=gateway-tcproute, logging "ListenerSet ns/name not found for
TCPRoute ns/name", while the reporter says an equivalent HTTPRoute
against the same ListenerSet worked.

ListenerSet resolution lives in a single code path shared by every
Gateway API route kind (resolveParentRef/routeIsAllowed in
source/gateway.go), but source/gateway_listenerset_test.go only ever
exercised it against HTTPRoute. TCPRoute+ListenerSet had zero test
coverage, so a regression there could ship unnoticed.

Approach:
Investigated by adding a probe test that builds a Gateway (TCP
listener) + ListenerSet (TCP listener) + TCPRoute referencing the
ListenerSet, with GatewayListenerSets: true. It passed on current
HEAD: TCPRoute already resolves correctly through a ListenerSet. The
existing TestGatewayHTTPRouteWithListenerSetDisabled test also shows
that with the flag left at its default (false), even HTTPRoute against
a ListenerSet produces zero endpoints (not an error) - the same
"not found" behavior the issue describes applies uniformly to every
route kind, since the gating logic has no per-kind branching.

That points to the issue being caused by --gateway-listener-sets not
being enabled (it defaults to false and requires Gateway API v1.5+
CRDs), matching the suggestion already left on the issue by another
community member, rather than a code defect in this repository.
Fabricating a source change for a bug that doesn't reproduce would be
worse than doing nothing, so instead this PR turns the probe into a
permanent regression test, TestGatewayTCPRouteWithListenerSetParentRef,
modeled on the existing HTTPRoute version and using the
hostname-annotation pattern already used by TestGatewayTCPRouteSourceEndpoints
(TCPRoute has no Hostnames() field). Mutation testing (temporarily
short-circuiting the ListenerSet lookup for TCPRoute only) confirmed
this new test fails when TCPRoute-specific resolution breaks, while
the existing HTTPRoute test does not catch that case - so it adds
real, non-overlapping coverage of this shared path.

No production code changes; user-visible behavior is unchanged.

Validation:
go test ./source/... -run TestGatewayTCPRouteWithListenerSetParentRef -v   (PASS)
go test -race ./source/...                                                (PASS, no regressions)
go build ./...                                                            (clean)
go vet ./source/...                                                       (clean)
gofmt -l source/gateway_listenerset_test.go                               (no output)

Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
Copilot AI review requested due to automatic review settings July 24, 2026 23:24
@kubernetes-prow kubernetes-prow Bot added the do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. label Jul 24, 2026
@linux-foundation-easycla

linux-foundation-easycla Bot commented Jul 24, 2026

Copy link
Copy Markdown

CLA Signed
The committers listed above are authorized under a signed CLA.

  • ✅ login: pujitha24 / name: Pujitha Paladugu (547b0ff)

@kubernetes-prow

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign mloiseleur for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found 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

@kubernetes-prow kubernetes-prow Bot added source cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Jul 24, 2026
@kubernetes-prow

Copy link
Copy Markdown

Welcome @pujitha24!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

@kubernetes-prow

Copy link
Copy Markdown

Hi @pujitha24. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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.

@kubernetes-prow kubernetes-prow Bot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jul 24, 2026

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

Adds a regression test to ensure the gateway-tcproute source correctly resolves a TCPRoute whose parentRef targets a ListenerSet when --gateway-listener-sets is enabled, preventing a repeat of #6557.

Changes:

  • Add TestGatewayTCPRouteWithListenerSetParentRef covering the Gateway → ListenerSet → TCPRoute resolution path.
  • Use the shared hostname annotation key constant for the TCPRoute hostname (annotations.HostnameKey).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@kubernetes-prow kubernetes-prow Bot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Jul 24, 2026
@mloiseleur mloiseleur changed the title test(source): add regression coverage for TCPRoute referencing a ListenerSet (#6557) test(source): add regression coverage for TCPRoute referencing a ListenerSet Jul 28, 2026
@mloiseleur

Copy link
Copy Markdown
Collaborator

@pujitha24 You need to fix the invalid commit message before we can proceed with the review. See #6578 (comment)

@kubernetes-prow kubernetes-prow Bot removed the do-not-merge/invalid-commit-message Indicates that a PR should not merge because it has an invalid commit message. label Aug 1, 2026
@ivankatliarchuk

Copy link
Copy Markdown
Member

/ok-to-test

@kubernetes-prow kubernetes-prow 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 Aug 2, 2026
@coveralls

Copy link
Copy Markdown

Coverage Report for CI Build 30717423597

Warning

Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes.
Quick fix: rebase this PR. Learn more →

Coverage remained the same at 81.697%

Details

  • Coverage remained the same as the base build.
  • Patch coverage: No coverable lines changed in this PR.
  • No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 21390
Covered Lines: 17475
Line Coverage: 81.7%
Coverage Strength: 1457.09 hits per line

💛 - Coveralls

@ivankatliarchuk

Copy link
Copy Markdown
Member

I'm not fully understand what this test is asserting. it does correctly assert that TCPRoute+ListenerSet resolution works, mirroring existing HTTPRoute coverage. But it is not a regression guard for issue #6557 as claimed. If #6557 recurs, this test would not have caught it, and merging this PR with "Fixes #6557" would close the issue without addressing its actual root cause. This test never goes red. It doesn't fail without a fix and pass with one — there is no fix in this PR (confirmed: zero production code changed), and it also doesn't fail on the pre-issue codebase. So it can't be "locking in" a fix, because nothing here demonstrates the bug ever existed in this code path. Just my assumption, but the bug itself seems like an informer cache-sync race, or most likely RBAC restricting list/watch on ListenerSet (which would silently produce an empty lister in prod but isn't modeled by the fake clientset at all), or some interaction specific to running --source=gateway-tcproute and --source=gateway-httproute together in the same long-running process. None of that is exercised here.

Maybe it should be reframed the PR as "adds TCPRoute+ListenerSet coverage"

The bug from issue #6557 :

  • the bug only manifested when a TCPRoute existed without a co-located HTTPRoute referencing the same ListenerSet. Once an HTTPRoute was also added, the TCPRoute's DNS record started working.

The test comment claimed it guards against kubernetes-sigs#6557, but as pointed out
in review it can't be a regression guard: nothing in this PR fails
without a fix and passes with one. Reword it to describe what it
actually does — TCPRoute+ListenerSet coverage for the shared
resolveParentRef/routeIsAllowed path — without claiming to reproduce
or guard against the reported issue.

Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com>
@pujitha24

Copy link
Copy Markdown
Contributor Author

You're right, and I've reworded the test comment and the PR description accordingly — it's coverage for the TCPRoute+ListenerSet path, not a regression guard for #6557, and I dropped Fixes #6557 in favor of Relates to #6557 so merging won't close the issue. I don't have a confirmed root cause either; your theories (RBAC on ListenerSet list/watch, cache-sync race, or the dual-source interaction) all seem more plausible than my flag-not-enabled guess, and none of them are exercised by this test. Happy to look further into the dual-source interaction if that's worth pursuing, but wanted to get the mislabeling fixed first.

@pujitha24

Copy link
Copy Markdown
Contributor Author

/assign @mloiseleur

Reworded per the earlier feedback (now framed as added coverage, not a fix, and Relates to instead of Fixes) — flagging for approval whenever you have a moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. source

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TCPRoute labels not working if referencing a ListenerSet

5 participants