AlinsRan commented on PR #13629: URL: https://github.com/apache/apisix/pull/13629#issuecomment-4860951216
Confirmed — thanks, this is a real multi-worker gap. A worker that never held the checker in its own `working_pool` reaches `create_checker()`, which only added targets, so a node removed after a peer worker populated the shared shm lingered there and kept being probed / returned by `/v1/healthcheck`. Fixed in d745b2f8d: `create_checker()` now also removes targets that are in the shm but absent from the config, reconciling it to the desired set. One note on the exact approach: I kept the existing "add all desired nodes" pass and added a "remove stale" pass, rather than swapping the body for `sync_checker_targets()`. `sync_checker_targets()` only **adds missing** targets (`if not current[key]`), so it would not re-add an already-present target — and re-adding is what clears a `purge_time` set by a concurrent `delayed_clear()` on a checks-config rebuild. Switching to it would reintroduce the "surviving targets purged after a rebuild" issue. So `create_checker()` does add-all (un-marks) + remove-stale (your fix). Regression test (`healthcheck-incremental-update.t` TEST 5): seed the shared shm with a node the config doesn't have (simulating the peer worker), then let this worker go through `create_checker()`, and assert `/v1/healthcheck` no longer reports the stale node. Verified locally — it **fails before** the fix (`stale_1970: true`) and **passes after** (`stale_1970: false`). -- 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]
