hanzhenfang commented on issue #14045: URL: https://github.com/apache/apisix/issues/14045#issuecomment-6260727328
Hi @NighterHunter, thanks for the report. We compared the `iter_and_add_healthcheck_info` implementation in APISIX 3.18.0 and 3.19.0, and tested the route shape from this issue with two `ai-proxy-multi` instances. The relevant difference is that [3.18.0](https://github.com/apache/apisix/blob/3.18.0/apisix/control/v1.lua#L103-L116) only adds health checks configured on the resource or its upstream. [3.19.0](https://github.com/apache/apisix/blob/3.19.0/apisix/control/v1.lua#L154-L167) retains that logic and adds the following call to collect health checks owned by plugins ([PR #13899](https://github.com/apache/apisix/pull/13899)): ```diff for _, value in core.config_util.iterate_values(values) do local checks = value.value.checks or (value.value.upstream and value.value.upstream.checks) if checks then local info = extra_checker_info(value) info.type = get_checker_type(checks) core.table.insert(infos, info) end + add_plugin_healthcheck_info(infos, value) end ``` We also ran one isolated test per version using the same sanitized route configuration. The external model endpoint was replaced with a local HTTPS mock; the second instance used a local HTTP mock. Business requests reached both model endpoints, and the active health probes to both endpoints succeeded. | Version tested | `GET /v1/healthcheck` after the route was used | Observation | | --- | --- | --- | | Official `apache/apisix:3.18.0-debian` | HTTP 200, `{}` | Reproduced an empty health-check listing even after requests reached both instances and both active probes returned 200. | | Official `apache/apisix:3.19.0-debian` | HTTP 200, two `ai-proxy-multi` instance entries, each with a healthy node | The empty-listing behavior did not reproduce in this test. | The **complete function** quoted in the issue matches 3.18.0: it ends without the `add_plugin_healthcheck_info(infos, value)` call. That call is present in the official 3.19.0 source. This makes a version or build mismatch worth checking, but our isolated tests cannot establish which build is running in your environment. Could you please confirm the exact APISIX version and build of the node that answered `/v1/healthcheck` (for example, its image digest or Git commit), and whether its runtime `apisix/control/v1.lua` contains the added call? If it is running the official 3.19.0 code, please also share the raw HTTP status, headers, and body of one affected `/v1/healthcheck` response and the effective route configuration on that same node, with credentials removed. These will help us identify where its behavior differs from our 3.19.0 test. -- 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]
