{"record":{"id":"38de8f0104e4d329","repo":"alibaba/nacos","slug":"400-38de8f","errorCode":"400","errorMessage":"health check is still working, service: %s@@%s, cluster: %s","messagePattern":"health check is still working, service: (.+?)@@(.+?), cluster: (.+?)","errorType":"validation","errorClass":"NacosException","httpStatus":null,"severity":"warning","filePath":"naming/src/main/java/com/alibaba/nacos/naming/core/HealthOperatorV2Impl.java","lineNumber":118,"sourceCode":"        for (Class<? extends AbstractHealthChecker> clazz : classes) {\n            try {\n                AbstractHealthChecker checker = clazz.newInstance();\n                checkerMap.put(checker.getType(), checker);\n            } catch (InstantiationException | IllegalAccessException e) {\n                Loggers.EVT_LOG.error(\"checkers error \", e);\n            }\n        }\n        \n        return checkerMap;\n    }\n    \n    private void throwHealthCheckerException(String groupName, String serviceName,\n        String clusterName)\n        throws NacosException {\n        String errorInfo =\n            String.format(\"health check is still working, service: %s@@%s, cluster: %s\", groupName,\n                serviceName, clusterName);\n        throw new NacosException(NacosException.INVALID_PARAM, errorInfo);\n    }\n}\n","sourceCodeStart":100,"sourceCodeEnd":121,"githubUrl":"https://github.com/alibaba/nacos/blob/9b989acdf181d00898f2e8839257bb2b2a3cefe3/naming/src/main/java/com/alibaba/nacos/naming/core/HealthOperatorV2Impl.java#L100-L121","documentation":"Thrown by HealthOperatorV2Impl.throwHealthCheckerException with INVALID_PARAM=400 when a health check update for a service+cluster is rejected because a health check is still running for that combination. This prevents conflicting concurrent health-check configuration changes.","triggerScenarios":"Calling the health-check update API for a groupName/serviceName/clusterName combination that already has an in-progress health check operation. The throwHealthCheckerException is invoked when the system detects the check is still active.","commonSituations":"Rapid successive health-check config updates for the same service+cluster. Concurrent admin operations targeting the same cluster. A previous health-check update did not complete (stuck or slow) and a new one was attempted. Automation loop re-triggering updates too frequently.","solutions":["Wait for the in-progress health check to complete before retrying the update.","Add a delay or backoff between successive health-check config changes for the same service+cluster.","Check server-side logs for the stuck/slow health check and resolve the underlying cause.","Serialize health-check updates per service+cluster to avoid concurrent conflicts."],"exampleFix":null,"handlingStrategy":"retry","validationCode":null,"typeGuard":null,"tryCatchPattern":"int maxAttempts = 3;\nlong delay = 1000;\nfor (int i = 0; i < maxAttempts; i++) {\n    try {\n        healthOperator.updateHealthCheck(...);\n        break;\n    } catch (NacosException e) {\n        if (e.getMessage().contains(\"health check is still working\")) {\n            Thread.sleep(delay);\n            delay *= 2;\n        } else { throw e; }\n    }\n}","preventionTips":["Serialize health-check config updates per service+cluster to avoid concurrent conflicts.","Add backoff between successive health-check operations for the same cluster.","Monitor for stuck health checks on the server side that block new updates."],"tags":["naming","health-check","conflict","concurrency","admin-api"],"backgroundTag":null,"analyzedSha":"9b989acdf181d00898f2e8839257bb2b2a3cefe3","analyzedAt":"2026-08-14T07:17:31.569Z","schemaVersion":2},"datasetVersion":"2026-08-14T10:17:34.591Z"}