Skip to content

TenantGateway reports Accepted=True for a route whose sectionName names no listener #3764

Open

Description

A route attached to a tenant Gateway with parentRef.sectionName naming a listener the controller does not render is told Accepted=True by gateway.cozystack.io/tenantgateway-controller. It cannot attach to anything: the section names nothing, so no listener carries its hostname on its behalf.

Eligibility asks which listener answers the claimed hostname, and only consults the sectionName when that section resolves to a rendered listener. A section naming nothing at all falls through as servable, because refusing it there would misname the cause: the route is unserved for a reason the withdrawal machinery does not model.

Two consequences, both status-only. The route's owner sees Accepted=True and no indication that the name they typed matches no listener, which is the one thing that would point them at the typo. And on a hostname a passthrough listener answers, that route stays in the ownership race for the TLS recount and can sort first, at which point a route that genuinely could attach is told it lost the hostname to a route Gateway API will never let attach.

The behaviour predates the TLS-passthrough listener work: before it, sectionName played no part in eligibility at all, so such a route reported Accepted=True for a different reason. It is pinned in TestReconcile_TLSRouteVerdictTable as the row section names no listener, attached namespace, with a comment saying closing the gap means flipping that row rather than discovering it.

Closing it means judging the section itself: a sectionName that resolves to no rendered listener is a refusal in its own right, and Gateway API has a reason for it, NoMatchingParent, defined for a parentRef whose port or section matches no listener on the Gateway. That is a new withdrawal cause with its own message rather than a change to any existing one.

No traffic impact: the data plane is unaffected either way, and Cilium writes its own RouteParentStatus entry under a different controller name.

Activity

  1. added
    kind/bugCategorizes issue or PR as related to a bug
    area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)
    triage/acceptedIndicates an issue is ready to be actively worked on
    priority/backlogGeneral backlog priority. Lower than priority/important-longterm
    and removed
    triage/needs-triageIndicates an issue needs triage by a maintainer
    on Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)kind/bugCategorizes issue or PR as related to a bugpriority/backlogGeneral backlog priority. Lower than priority/important-longtermtriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions