apache/incubator-seata · error · ServiceCallException

MCP DELETE Call TC Failed.

Error message

MCP DELETE Call TC Failed.

What it means

deleteCallTC wraps any RestClientException from the HTTP DELETE to a TC into ServiceCallException('MCP DELETE Call TC Failed.'). It indicates the delete request never got a response — connection refused, timeout, I/O error — as distinct from a TC that answered with an error status (error 118).

Source

Thrown at console/src/main/java/org/apache/seata/mcp/service/impl/ConsoleRemoteServiceImpl.java:207

        HttpEntity<String> entity = new HttpEntity<>(headers);
        String responseBody;
        try {
            ResponseEntity<String> response = executeRequest(url, HttpMethod.DELETE, entity);

            responseBody = response.getBody();

            if (!response.getStatusCode().is2xxSuccessful()) {
                String errorMsg = String.format(
                        "MCP DELETE request returned non-success status: %s, response: %s",
                        response.getStatusCode(), response.getBody());
                LOGGER.warn(errorMsg);
                throw new ServiceCallException(errorMsg, response.getStatusCode());
            }
            return responseBody;
        } catch (RestClientException e) {
            String errorMsg = "MCP DELETE Call TC Failed.";
            LOGGER.error(errorMsg, e);
            throw new ServiceCallException(errorMsg);
        }
    }

    @Override
    public String putCallTC(
            NameSpaceDetail nameSpaceDetail,
            String path,
            Object objectQueryParams,
            Map<String, String> queryParams,
            HttpHeaders headers) {
        if (headers == null) {
            headers = new HttpHeaders();
        }
        if (nameSpaceDetail == null || !nameSpaceDetail.isValid()) {
            return "If you have not specified the namespace of the TC/Server, specify the namespace first";
        } else {
            setNamespaceHeaderAndQueryParam(nameSpaceDetail, headers, queryParams);
        }

View on GitHub (pinned to e01f97c6db)

Solutions

1. Confirm the TC is reachable (health endpoint) before issuing deletes
2. Treat this exception as outcome-unknown: re-query the transaction by xid afterwards instead of blindly re-deleting
3. Fix stale naming-server registrations by restarting/re-registering the TC
4. Increase REST timeouts for long-running force operations and add idempotent retry keyed on the xid

if (!tcHealthEndpointReachable(tcAddr)) throw new IllegalStateException("TC unreachable, delete may be unsafe: " + tcAddr);

try { service.deleteCallTC(...); } catch (ServiceCallException e) { if (isTransportFailure(e)) { reQueryByXid(xid); if (stillActive) retryWithBackoff(); } else throw e; }

When it happens

Trigger: Issuing a console/MCP delete while the target TC is unreachable: process down, wrong address in naming-server registry, network partition, or the delete exceeds the REST client timeout.

Common situations: TC crash/restart windows while an admin performs cleanup; stale TC registration after scale-down; unreachable container ports in Kubernetes networking; slow force-rollback operations exceeding the configured timeout so the outcome is unknown.

Related errors

• MCP GET Call TC Failed.
• MCP DELETE request returned non-success status: %s, response
• MCP GET Call NameSpace Failed.
• No naming servers addr configured
• The time format does not match yyyy-MM-dd

AI-assisted analysis of apache/incubator-seata@e01f97c6db (2026-08-14). Data as JSON: /api/errors/f7b475eb17e465d9. Report an issue: GitHub.