HTTPRoute status.parents empty or stale on first create under parallel applies (EG v1.9.2, GKE, hostless HTTPS listener)

[sravula84]

Context

We're rolling out Envoy Gateway on GKE (Gateway API) and attaching many app HTTPRoutes to one shared Gateway (external HTTPS listener, hostless — no hostname on the listener; routes use parentRefs with sectionName: https).

• Envoy Gateway: v1.9.2 (Helm gateway-helm-v1.9.2)
• Scale: on the order of ~15–20 HTTPRoutes in a short window (CI deploy batches, Helm create/upgrade)
• Gateway: single shared Gateway; HTTPRoutes are standard host-based routes to Services

What we see

On first create (especially when several HTTPRoutes land in parallel):

1. status.parents is empty [], or shows a parent row with Accepted=False (wording varies).
2. Data plane often looks fine: routes show up in Envoy / Gateway status attachedRoutes counts; port-forward or internal checks can match nginx-era behavior.
3. Delete the HTTPRoute and recreate (same spec) usually fixes status → Accepted=True with no spec change.

We are not seeing a consistent NoMatchingListenerHostname story — parentRef (Gateway name, namespace, sectionName: https) matches what works after recreate.

Workarounds we use

• Smaller parallel batches on first HTTPRoute wave (e.g. 2–3 instead of 5).
• Post-deploy gate: fail CI/ops if any route is not Accepted=True before load balancer cutover.
• Optional: bump a harmless HTTPRoute annotation on each Helm revision to force reconciliation (helps sometimes; not a root fix).

Questions for the community / maintainers

1. Is this a known class of status write / reconcile lag under concurrent HTTPRoute creates? Anything we should tune (controller flags, debounce, QPS)?
2. Related issues: #8861 (and possibly #8876) — does our empty parents on first create belong on one of those, or is a minimal repro still wanted for v1.9.x?
3. Recommended upgrade path: any release in the v1.9 / v1.10 line where HTTPRoute status reconciliation on create was explicitly improved?

Thanks.

[dfbustosus]

This is a known class of behavior in Gateway API controllers, and your "delete + recreate fixes it, spec unchanged" signature is the tell: the route's status subresource was written once from a partially-initialized world (Gateway not yet Ready/Programmed, listener not yet attached) and nothing re-triggered the status writer afterward — the data plane and attachedRoutes keep updating because they're computed on every envoy config rebuild, but status.parents for a given route is only recomputed on watch events touching that route or its parent Gateway, so a status write that landed during the init window can go stale until the next such event. Parallel first-wave creates amplify the window (and add status-update conflicts under burst, where a failed optimistic-concurrency write can also leave the row unwritten if the retry isn't re-queued).

Two things worth separating in your rollout:

1. Sequencing eliminates most of it. Since this is a first-create phenomenon on a shared Gateway, gate the route wave on Gateway readiness in CI before applying routes:

kubectl wait gateway/<name> -n <gw-ns> --for=condition=Programmed --timeout=300s

then apply the HTTPRoutes (any batch size). If the listener/hostname story is already consistent by the time routes land, the stale-status window mostly disappears — which matches your smaller-batches improvement, just made deterministic.

2. Your annotation-bump workaround is the right remediation for stragglers — it forces exactly the missing watch event. A post-deploy loop that bumps (or even re-applies) any route not Accepted=True within N seconds would turn your CI gate into a self-healing one.

On tuning: there's no user-facing flag that changes this — the relevant knobs (status writer queueing, per-route requeue on parent-Gateway events) are internal, and the burst-conflict behavior is worth an upstream issue with your repro details (version, parallel create count, stale-until-recreate signature), since re-queueing route status on Gateway Ready transitions is a fixable controller gap rather than inherent Gateway API semantics.