test/e2e/gateway: check service as part of request condition

[skriss]

For the RequestHeaderModifierBackendRef test, check the service reached by the request as part of the
eventual consistency condition to avoid issues with test pollution.

ref. https://github.com/projectcontour/contour/actions/runs/8179127307/job/22364621818

Oddly, when failing, the request is hitting an "echo" backend pod, which isn't even defined as part of the test in question (it only has "echo-header-filter" and "echo-header-nofilter"). There must be some pollution going on from another test, but I can't spot it. It's a little odd given that the HTTPRoute has a distinct hostname that's being used in the requests. In any case, I think this should help avoid issues. Haven't been able to repro locally.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.33%. Comparing base (e64a50a) to head (21d4562).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6251   +/-   ##
=======================================
  Coverage   81.33%   81.33%           
=======================================
  Files         133      133           
  Lines       15775    15775           
=======================================
  Hits        12831    12831           
  Misses       2650     2650           
  Partials      294      294           

[sunjayBhatia]

hm, one hint in the logs from the linked test run is:

time="2024-03-06T21:52:05Z" level=debug msg="nodeID \"contour\" requested type.googleapis.com/envoy.config.route.v3.RouteConfiguration[https-443/*.wildcardhost.gateway.projectcontour.io] and known map[https-443/*.wildcardhost.gateway.projectcontour.io:{}]. Diff []" context=defaultCache

which would mean the failing test runs after this one:

contour/test/e2e/gateway/tls_wildcard_host_test.go

Line 45 in 7ab1748

Hostnames: []gatewayapi_v1.Hostname{"*.wildcardhost.gateway.projectcontour.io"},

curiously that test passes making HTTPS requests as expected, but I wonder if the failures in testRequestHeaderModifierBackendRef with plain HTTP request pollution point to an issue with the wildcard route

[sunjayBhatia]

hm, one hint in the logs from the linked test run is:

time="2024-03-06T21:52:05Z" level=debug msg="nodeID \"contour\" requested type.googleapis.com/envoy.config.route.v3.RouteConfiguration[https-443/*.wildcardhost.gateway.projectcontour.io] and known map[https-443/*.wildcardhost.gateway.projectcontour.io:{}]. Diff []" context=defaultCache

which would mean the failing test runs after this one:

contour/test/e2e/gateway/tls_wildcard_host_test.go

Line 45 in 7ab1748

Hostnames: []gatewayapi_v1.Hostname{"*.wildcardhost.gateway.projectcontour.io"},

curiously that test passes making HTTPS requests as expected, but I wonder if the failures in testRequestHeaderModifierBackendRef with plain HTTP request pollution point to an issue with the wildcard route

this is very hard to repro though locally since it would rely on the previous test configuration still existing in envoy while a new configuration is being added and our logic on wildcard hosts somehow being wrong, which I don't think is the case...

[sunjayBhatia]

we could also maybe outlaw using echo as a backend name and always use unique names to fish this one out too

[sunjayBhatia]

eh also the *.wildcardhost... test being the culprit also doesn't really make sense bc it doesn't set up any HTTP Listener at all, Gateways in all our tests only allow routes from the same namespace, etc.

the only other test that could be a culprit would be testTCPRoute which sets up a TCPRoute and Gateway with a Listener on port 80 and ofc doesn't have any hostname involvement