flaky: TestMergeGateways/BasicMergeGateways

[zirain]

https://github.com/envoyproxy/gateway/actions/runs/8865654957/job/24342242631

[shawnh2]

By debugging this, found that gateway

gateway/test/e2e/testdata/basic-merge-gateways.yaml

Line 34 in 2f916e5

name: merged-gateway-3

and gateway

gateway/test/e2e/testdata/basic-merge-gateways.yaml

Line 49 in 2f916e5

name: merged-gateway-4

may cause racing status handling since they have same listener settings (even if is on purpose), we cannot predict either which gateway finally got accepted or which gateway reports conflicted.

so the workaround here is to manully apply merged-gateway-4 that has the same listener settings as in merged-gateway-3, so we can make sure the merged-gateway-4 always has conflicted listener.

[shawnh2]

reopen this, discovery some new error of this e2e test case.

• https://github.com/envoyproxy/gateway/actions/runs/8979831123/job/24662614331?pr=2951
• https://github.com/envoyproxy/gateway/actions/runs/8981271018/job/24666740500#step:6:16359
• https://github.com/envoyproxy/gateway/actions/runs/8981501021/job/24667380311?pr=3303#step:6:16386

[shawnh2]

the conflicted gateway could not get expected status, since EG will recompute each resources status, the Conflict status may randomly falls on gateway-3 or gateway-4.

so here're 2 ways to solve this:

• create gateway-3 also manually like what we did to gateway-4, but cannot promise this e2e test case to be stable
• create gateway-3 and gateway-4 in manifest file like the old way, but check conflict status to be in one of them

---

let's go with way-2, the way-1 is basically the same as old commit.

[shawnh2]

reopen, still found flakiness: https://github.com/envoyproxy/gateway/actions/runs/9122382545/job/25083245410#step:6:16915

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[shawnh2]

closed in favor of #3845