alibaba/nacos · critical · ConnectException

[NACOS HTTP-DELETE] The maximum number of tolerable server r

Error message

[NACOS HTTP-DELETE] The maximum number of tolerable server reconnection errors has been reached

What it means

Thrown by ServerHttpAgent.httpDelete when the retry budget is exhausted during a DELETE (config removal). Same loop/maxRetry logic as GET/POST. Appears when removing a config and every server fails, decrementing maxRetry below zero before the deadline.

Source

Thrown at client/src/main/java/com/alibaba/nacos/client/config/http/ServerHttpAgent.java:233

                    ExceptionUtil.getStackTrace(connectException));
            } catch (SocketTimeoutException stoe) {
                LOGGER.error(
                    "[NACOS SocketTimeoutException httpDelete] currentServerAddr:{}， err : {}",
                    serverListMgr.getCurrentServer(), ExceptionUtil.getStackTrace(stoe));
            } catch (Exception ex) {
                LOGGER.error(
                    "[NACOS Exception httpDelete] currentServerAddr: "
                        + serverListMgr.getCurrentServer(),
                    ex);
                throw ex;
            }
            
            if (serverListMgr.getIterator().hasNext()) {
                currentServerAddr = serverListMgr.getIterator().next();
            } else {
                maxRetry--;
                if (maxRetry < 0) {
                    throw new ConnectException(
                        "[NACOS HTTP-DELETE] The maximum number of tolerable server reconnection errors has been reached");
                }
                serverListMgr.refreshCurrentServerAddr();
            }
            
        } while (System.currentTimeMillis() <= endTime);
        
        LOGGER.error("no available server");
        throw new ConnectException("no available server");
    }
    
    private String getUrl(String serverAddr, String relativePath) {
        String contextPath = serverListMgr.getContextPath();
        return serverAddr + ContextPathUtil.normalizeContextPath(contextPath) + relativePath;
    }
    
    private boolean isFail(HttpRestResult<String> result) {
        return result.getCode() == HttpURLConnection.HTTP_INTERNAL_ERROR

View on GitHub (pinned to 9b989acdf1)

Solutions

Confirm server availability and that the DELETE route is permitted (auth, firewall).
Check the preceding per-server log lines for the actual transport error.
Increase retry budget / timeout if transient.
Verify the access token/credentials are valid (403 can cascade into repeated failures).

Defensive patterns

Strategy: retry

Validate before calling

// verify DELETE endpoint is reachable and auth is valid before removing
// (no public pre-check API; rely on health endpoint + valid token)

Try / catch

try {
    configService.removeConfig(dataId, group);
} catch (Exception e) {
    if (e.getMessage().contains("HTTP-DELETE")) {
        log.error("delete failed on all servers", e);
    }
}

Prevention

Ensure credentials/token are valid to avoid cascading 403s on DELETE.
Confirm the cluster is up before destructive ops.
Log the per-server errors preceding the terminal throw.

When it happens

Trigger: configService.removeConfig / DELETE request where all servers return failure codes or throw connection errors, exhausting maxRetry.

Common situations: Removing a config during a cluster outage, all nodes unreachable, or a gateway returning 5xx for DELETE.

Related errors

AI-assisted analysis of alibaba/nacos@9b989acdf1 (2026-08-14). Data as JSON: /api/errors/e13462cc3845705b. Report an issue: GitHub.