Fixes a bug where if a check existed in a namespace, although the check would run - the status would not be updated as ESM incorrectly determined that the check had been deregistered.
/v1/health/node/:node will not return checks in all namespaces by default, therefore we were incorrectly returning early from handleUpdateCheck if the check we were looking for was associated to a service in a different namespace from our Consul token.
We now pass the namespace stored against the check when querying to make sure the check still exists. This should be safe for both Consul OSS and Enterprise, checks for OSS will just send "default" as the namespace for every call - need to double check though as some endpoints will return a 400 when passed the ns query param.
Testing & reproduction steps
Tricky to add test coverage for this, since it requires Consul Enterprise. Tested in a real deployment with Consul Enterprise and verified that this resolves the issue.
To reproduce original bug
Register a node, e.g. "node1".
Create a new namespace, e.g. "ns1".
Register a service, with a check, in "ns1" and associate with the "node1".
Run Consul ESM, the check will be detected and executed - but the status is never updated and nothing is logged.
Description
Fixes a bug where if a check existed in a namespace, although the check would run - the status would not be updated as ESM incorrectly determined that the check had been deregistered.
/v1/health/node/:nodewill not return checks in all namespaces by default, therefore we were incorrectly returning early fromhandleUpdateCheckif the check we were looking for was associated to a service in a different namespace from our Consul token.We now pass the namespace stored against the check when querying to make sure the check still exists. This should be safe for both Consul OSS and Enterprise, checks for OSS will just send "default" as the namespace for every call - need to double check though as some endpoints will return a 400 when passed the
nsquery param.Testing & reproduction steps
Tricky to add test coverage for this, since it requires Consul Enterprise. Tested in a real deployment with Consul Enterprise and verified that this resolves the issue.
To reproduce original bug
Links