nic-6443 opened a new pull request, #13703:
URL: https://github.com/apache/apisix/pull/13703

   ### Description
   
   `t/plugin/error-log-logger-kafka.t` TEST 10 fails intermittently, for 
example in [this 
run](https://github.com/apache/apisix/actions/runs/29495384161):
   
   ```
   Failed test 't/plugin/error-log-logger-kafka.t TEST 10: put metadata with 
kafka tls and log an
   error message - send via TLS - pattern "(?^:sending a batch logs to kafka 
brokers:
   \[\{"host":"127.0.0.1","port":9093\}\])" should match a line in error.log 
(req 0)'
   ```
   
   This is not a timing problem. The block asserts the broker list against a 
literal string:
   
   ```perl
   qr/sending a batch logs to kafka brokers: 
\[\{"host":"127.0.0.1","port":9093\}\]/
   ```
   
   but the plugin produces it with 
`core.json.delay_encode(config.kafka.brokers)` 
(`apisix/plugins/error-log-logger.lua:391`), and cjson serialises a Lua table 
in hash order. That order is not stable between runs, so the encoder sometimes 
emits the keys the other way round and the pattern misses a line that is 
present.
   
   Running the block 12 times shows both encodings:
   
   ```
   9x  [{"host":"127.0.0.1","port":9093}]   -> matches the pattern, passes
   3x  [{"port":9093,"host":"127.0.0.1"}]   -> does not match, fails
   ```
   
   The giveaway in a failing run is that the *later* message matches while the 
batch line does not, which cannot happen if the line were merely late:
   
   ```
   ok 3 - ... pattern "(?^:send data to kafka: .*this is a error message for 
tls test)" matches a line
   not ok 4 - ... pattern "(?^:sending a batch logs to kafka brokers: 
\[\{"host":"127.0.0.1","port":9093\}\])"
   ```
   
   ### Change
   
   Match the host and the port as two independent patterns, so the assertion 
holds whatever order the encoder picks and still checks both values. This 
follows the same order-tolerant style already used in TEST 2 of this file 
(`qr/broker_config is: \{.*"refresh_interval":1000/`).
   
   ### How this was verified
   
   Against a local kafka with the TLS listener from #13607, running the block 
in isolation:
   
   - before the change: 12 runs, the 3 that encoded port-first failed, the 9 
that encoded host-first passed;
   - after the change: 14 runs, all passed, including 3 that encoded port-first.
   
   Raising `--- wait` does **not** fix this — I tried it, and a run still 
failed with the batch line flushed 1s after the error was logged, well inside 
the window.
   
   ### 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]

Reply via email to