kyrie4899 commented on issue #13385:
URL: https://github.com/apache/apisix/issues/13385#issuecomment-4561809661
Hi, I tried to reproduce this on a clean docker-compose APISIX 3.16.0 setup
but **could not reproduce** the long-lived stale node under these conditions.
**Environment**
- APISIX `3.16.0-debian` (official image)
- `apisix-docker/example/` docker-compose
- Upstream `99` with two HTTP nodes (`web1:80`, `web2:80`)
- Tested both `type: http` and `type: tcp` active healthcheck
**Steps**
1. `PUT /apisix/admin/upstreams/99` with two nodes + active healthcheck
2. Send a few requests to trigger healthcheck startup
3. Verify both nodes appear as `healthy` in `/v1/healthcheck`
4. `PATCH /apisix/admin/upstreams/99/nodes -d '{"web1:80":1}'` to remove
`web2`
5. Query `/v1/healthcheck` immediately, and again after 30s
**Observations**
- **Immediately after PATCH:** both nodes still appear in `/v1/healthcheck`,
and **both carry a `purge_time` field** (including the kept node). Looks like
the old checker instance is marked for purge, new one not yet created.
- **~30s later:** only `web1` remains. No `purge_time`. Clean state.
This matches @Baoyuantop's note about the old checker being cleared.
**Possible difference from @wangwei0326's report**
In the report, the stale node `10.205.102.167:8900` appears **without** a
`purge_time` field and persists for ~24h. In my reproduction the deleted node
always carries `purge_time` and disappears within ~30s.
So the bug may not be slow cleanup — there might be a code path where
`purge_time` is not set on the deleted node at all. Possibly related to
upstreams with the same IP on different ports (`8600` vs `8900` in the report).
Happy to run more targeted tests if useful.
--
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]
