apache/seatunnel · error · DorisConnectorException
COMMIT_FAILED
COMMIT_FAILED
Error message
<loadResult>
What it means
After committing a Doris stream-load transaction, the connector parses the commit response body (loadResult). If the HTTP call succeeded but the JSON result does not report success (and the message does not indicate the txn was already committed), the raw loadResult string is thrown as COMMIT_FAILED. The same string is logged with the commit URL and txn id for debugging.
Source
Thrown at seatunnel-connectors-v2/connector-doris/src/main/java/org/apache/seatunnel/connectors/doris/sink/committer/DorisCommitter.java:256
: responseStatus);
}
private void handleCommitSuccess(
DorisCommitInfo committable, String hostPort, CloseableHttpResponse response)
throws IOException {
ObjectMapper mapper = new ObjectMapper();
if (response.getEntity() != null) {
String loadResult = EntityUtils.toString(response.getEntity());
Map<String, String> res =
mapper.readValue(loadResult, new TypeReference<HashMap<String, String>>() {});
if (!LoadStatus.SUCCESS.equals(res.get("status"))
&& !ResponseUtil.isCommitted(res.get("msg"))) {
log.error(
"commit transaction error url:{},TxnId:{},result:{}",
String.format(COMMIT_PATTERN, hostPort, committable.getDb()),
committable.getTxbID(),
loadResult);
throw new DorisConnectorException(
DorisConnectorErrorCode.COMMIT_FAILED, loadResult);
} else {
log.info("load result {}", loadResult);
}
}
}
private void sleepBeforeNextAttempt(int attempt) throws IOException {
if (attempt < maxRetry) {
retrySleeper.sleep(attempt + 1);
}
}
private static void sleepBeforeRetry(int retry) throws IOException {
try {
int shift = Math.min(Math.max(retry - 1, 0), 4);
Thread.sleep(1000L * (1L << shift));
} catch (InterruptedException ie) {View on GitHub (pinned to cf67b549a7)
Solutions
- Read the loadResult string in the error/log — it contains Doris's own status and msg explaining the rejection
- Check the txn state with 'show transaction where id=<txbID>' to see if it was aborted/expired
- Increase Doris stream_load_default_timeout / txn timeout if checkpoint intervals are long
- If the txn does not exist, the data was likely already committed or aborted — verify with ResponseUtil's committed-message handling and check label status via 'show stream load'
- Retry the pipeline; persistent commit failures usually require investigating fe.log around the txn id
Defensive patterns
Strategy: try-catch
Try / catch
try { committer.commit(c); } catch (DorisConnectorException e) { /* parse e.getMessage() for Doris status/msg; check 'show transaction where id=<txbID>' */ } Prevention
- Set stream-load/txn timeouts comfortably larger than checkpoint interval
- Avoid duplicate labels across concurrent jobs writing the same table
- Inspect fe.log for the txn id when commits fail
When it happens
Trigger: DorisCommitter.handleCommitSuccess receives a commit response whose 'status' is not Success/OK and whose 'msg' is not a committed-txn message; e.g. 'Fail to get txn ...', 'txn not exist', label already used, or internal error.
Common situations: Committing a txn id that Doris already aborted or expired (long checkpoint intervals exceeding txn timeout); duplicate label from re-running a job; FE refusing the commit because the txn was rolled back after a previous failure; cluster overloaded.
Related errors
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/2107a56ad49c77d0.
Report an issue: GitHub.