flaky: TestMergeGateways/BasicMergeGateways
zirain opened this issue · comments
By debugging this, found that gateway
and gateway
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.
reopen this, discovery some new error of this e2e test case.
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.
reopen, still found flakiness: https://github.com/envoyproxy/gateway/actions/runs/9122382545/job/25083245410#step:6:16915