nic-6443 opened a new pull request, #14191: URL: https://github.com/apache/apisix/pull/14191
### Description Bump `lua-resty-redis-cluster` from `1.3.4-0` to `1.3.5-0`. `1.3.5` contains one change (api7/lua-resty-redis-cluster#25): every connect attempt, both during slot discovery and when a command is retried, now uses the caller's `connect_timeout` instead of a hard-coded 100 ms for the first attempt and 800 ms for retries. Send and read timeouts were already taken from the config, so after this the whole connection lifecycle follows one setting. The connect timeout also bounds the TLS handshake, so with `redis_cluster_ssl` enabled the 100 ms first attempt could be too short to complete the handshake on higher-latency links. For APISIX this means `redis_timeout` now actually governs connection establishment for the `redis-cluster` policy. `apisix/utils/rediscluster.lua` already passes `redis_timeout` as `connect_timeout` (and as send/read timeout), and every user of the policy goes through it: `limit-count` and the plugins built on it (`graphql-limit-count`, `ai-rate-limiting`, which copies the policy's fields from the `limit-count` schema), `limit-req` and `limit-conn`. In all of their schemas `redis_timeout` defaults to 1000 ms, so the change is visible without any config change: - connecting to a cluster node, including the TLS handshake, may now take up to `redis_timeout` (1000 ms by default) instead of being cut off at 100 ms on the first attempt, so TLS clusters on slower links stop failing the handshake; - the flip side is that a node that silently drops packets now holds each connect attempt for up to `redis_timeout` rather than 100/800 ms, so a request can wait longer before the limiter gives up or falls back. Lower `redis_timeout` to get faster failure, keeping in mind it also bounds send/read. The background health probe of nodes marked unhealthy keeps its own fixed 500 ms timeout; that is unchanged. The docs describe `redis_timeout` as "the Redis timeout value in milliseconds when `policy` is `redis` or `redis-cluster`", which is what it now is for both policies, so no doc change is needed. No new test here: the timeout behaviour is covered by the library's own test suite, and the existing redis-cluster tests (`limit-count-redis-cluster*.t`, `limit-req-redis-cluster.t`, `limit-conn-redis-cluster.t`, `graphql-limit-count.t`, `limit-count-rate-limiting-info.t`) keep passing with `1.3.5`. `lua-resty-redis-cluster-1.3.5-0` is published on LuaRocks. ### 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 - [ ] I have added tests corresponding to this change - [ ] I have updated the documentation to reflect this change - [x] I have verified that this change is backward compatible (If not, please discuss on the [APISIX mailing list](https://github.com/apache/apisix/tree/master#community) first) -- 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]
