nic-6443 opened a new pull request, #13701: URL: https://github.com/apache/apisix/pull/13701
### Description `t/kubernetes/discovery/kubernetes.t` TEST 3 fails intermittently on master, for example in [this run](https://github.com/apache/apisix/actions/runs/29374991834): ``` Failed test 't/kubernetes/discovery/kubernetes.t TEST 3: mixing set custom and default values - pattern "[error]" should not match any line in error.log but matches line "[error] ... [lua] informer_factory.lua:302: connect apiserver failed, apiserver.host: sample.com, apiserver.port: 6443, message : connection refused, context: ngx.timer" ``` TEST 3 is the only block in the file whose `service.host` is not the apiserver the job port-forwards to `127.0.0.1`, so its informer can never connect. Configuring `discovery.kubernetes` starts the informer regardless, it fails to connect in an `ngx.timer`, and it logs an `[error]`. The block sets neither `error_log` nor `no_error_log`, so `t/APISIX.pm` gives it the default `no_error_log: [error]` and the block fails — but only when the connect fails early enough to land inside the block's own window. Since each block here has its own `yaml_config`, nginx restarts between blocks and a slow-enough resolve means the timer is killed before it ever logs. That is what makes it intermittent rather than a hard failure. The block only compares the resolved configuration through `/compare` and never intends to reach an apiserver, so the connect error is expected noise rather than a defect. This overrides `no_error_log` for that block alone, using the same idiom already used elsewhere in `t/`. The neighbouring blocks are deliberately left alone: they point at `127.0.0.1`, which the job actually serves. ### How this was verified Running the file locally with nothing listening on `127.0.0.1:6443` inverts which host is reachable and reproduces the identical signature on the other blocks, while TEST 3 passes because the custom host happened to be connectable there: ``` TEST 1 ... matches line "[error] ... informer_factory.lua:302: connect apiserver failed, apiserver.host: 127.0.0.1, apiserver.port: 6443, message : connection refused, context: ngx.timer" TEST 2 ... (same) TEST 4 ... (same) TEST 6 ... (same) TEST 8 ... (same) ``` That confirms the mechanism: whichever block points at an apiserver the environment does not serve is the one the default `[error]` check trips on, and in CI that block is TEST 3. With an `[error]` present in TEST 3's window, the block fails before this change and passes after it. ### Checklist - [x] I have explained the need for this PR and the problem it solves - [x] I have explained the changes or the new features added to this PR - [x] I have added tests corresponding to this change - [x] I have updated the documentation to reflect this change - [x] I have verified that this change is backward compatible -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
