apache/incubator-seata · error · ServiceCallException
MCP DELETE request returned non-success status: %s, response
Error message
MCP DELETE request returned non-success status: %s, response: %s
What it means
deleteCallTC throws ServiceCallException when the HTTP DELETE forwarded to a TC instance returns a non-2xx status. The message embeds the TC's status code and body. This path serves destructive console operations (e.g. forcing global transaction rollback/removal), so failures here block the admin action.
Source
Thrown at console/src/main/java/org/apache/seata/mcp/service/impl/ConsoleRemoteServiceImpl.java:201
} else {
setNamespaceHeaderAndQueryParam(nameSpaceDetail, headers, queryParams);
}
headers.add(WebSecurityConfig.AUTHORIZATION_HEADER, getToken());
Map<String, Object> queryParamsMap = objectToQueryParamMap(objectQueryParams, objectMapper);
String url = buildUrl(namingServerProperties.getNamingServerUrl(), path, queryParams, queryParamsMap);
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();View on GitHub (pinned to e01f97c6db)
Solutions
- Check the embedded status/body — a 404 usually means the transaction is already gone, so refresh and confirm it still exists before retrying
- Guard against double-submission in the UI/tool client
- For 401/403 verify the JWT validates on the TC (shared secret) and the user may delete in that namespace
- For 500, inspect TC logs for the failing xid and address the server-side cause before retrying
Defensive patterns
Strategy: try-catch
Try / catch
try { service.deleteCallTC(...); } catch (ServiceCallException e) { if (status == 404) treat as already-deleted (idempotent success); else surface embedded body; } Prevention
- Refresh and confirm the transaction still exists right before delete
- Make delete flows idempotent on xid to tolerate 404
- Check user permissions on the TC for the target namespace
When it happens
Trigger: MCP/console delete operations against a TC that responds with an error: 404 when the target global transaction/session no longer exists (already rolled back or timed out), 401/403 auth rejection, or 500 on TC-side failure.
Common situations: Attempting to force-delete a global transaction that committed/rolled back between the list view and the delete click; double-submitting a delete; permission mismatches between console user and TC.
Related errors
- MCP DELETE Call TC Failed.
- MCP GET request failed with status: %s, response: %s
- MCP GET Call TC 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/a4f6f0c8305c51f7.
Report an issue: GitHub.