apache/shardingsphere · error · ServerResultException

Get %s response failed, code:%s, reason: %s

Error message

Get %s response failed, code:%s, reason: %s

What it means

When a CDC client request completes but the server attached an error message, waitResponseResult throws ServerResultException with the request type, error code, and server-side reason. This is the client-visible form of any server rejection (invalid parameters, job failures, internal errors) for that request.

Source

Thrown at kernel/data-pipeline/scenario/cdc/client/src/main/java/org/apache/shardingsphere/data/pipeline/cdc/client/util/ResponseFuture.java:75

    
    /**
     * Wait response result.
     *
     * @param timeoutMillis timeout milliseconds
     * @param connectionContext connection context
     * @return response result
     * @throws GetResultTimeoutException get result timeout
     * @throws ServerResultException server result exception
     */
    @SneakyThrows(InterruptedException.class)
    public Object waitResponseResult(final long timeoutMillis, final ClientConnectionContext connectionContext) {
        if (!countDownLatch.await(timeoutMillis, TimeUnit.MILLISECONDS)) {
            connectionContext.getResponseFutureMap().remove(requestId);
            throw new GetResultTimeoutException("Get result timeout");
        }
        connectionContext.getResponseFutureMap().remove(requestId);
        if (!Strings.isNullOrEmpty(errorMessage)) {
            throw new ServerResultException(String.format("Get %s response failed, code:%s, reason: %s", requestType.name(), errorCode, errorMessage));
        }
        return result;
    }
    
    /**
     * Count down.
     */
    public void countDown() {
        countDownLatch.countDown();
    }
}

View on GitHub (pinned to e952770a21)

Solutions

1. Read the 'reason' and 'code' in the message: they come directly from the proxy and identify the concrete server-side failure.
2. Check the proxy log at the same timestamp for the full server-side stack trace.
3. Fix the underlying request (credentials, database name, job state) and resend.
4. Ensure the CDC client version matches the proxy version to avoid rejected request shapes.

try {
    client.startSubscription(...);
} catch (final ServerResultException ex) {
    // message carries requestType, code and server reason; branch on them
    if (ex.getMessage().contains("already")) { /* idempotent success */ } else { throw ex; }
}

When it happens

Trigger: Calling a CDC client API (e.g. start subscription, stop subscription) where the proxy validates the request and returns an error payload instead of a result: nonexistent database, invalid username/password for the subscription, job already started, or an internal pipeline failure on the server.

Common situations: Subscribing with wrong database/user credentials; starting a subscription that is already running; server-side job exceptions (source unreachable, slot conflicts); version skew where the client sends a request the server rejects.

Related errors

• not support unpack the type %s
• Get result timeout
• MySQL BLOB type meta in binlog should be range 1 to 4, but a
• MySQL JSON type meta in binlog should be range 1 to 4, but a
• MySQL Enum meta in binlog only include value 1 or 2, but act

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/5cdce04186147724. Report an issue: GitHub.