What causes "rollback failed" in apache/seatunnel?

Inspect in-doubt transactions on the database (e.g. Oracle DBA_2PC_PENDING, MySQL XA RECOVER) and resolve them manually (XA COMMIT/ROLLBACK)

apache/seatunnel · error · JdbcConnectorException

XA_OPERATION_FAILED

XA_OPERATION_FAILED

Error message

rollback failed

What it means

JdbcSinkCommitter.abort rolls back the list of XA transactions (XidInfo) via XaGroupOps.rollback; any exception is rethrown as XA_OPERATION_FAILED with message 'rollback failed'. This means in-doubt XA transactions prepared by the sink could not be rolled back and may remain pending in the database.

Source

Thrown at seatunnel-connectors-v2/connector-jdbc/src/main/java/org/apache/seatunnel/connectors/seatunnel/jdbc/sink/JdbcSinkCommitter.java:69

        }
    }

    @Override
    public List<XidInfo> commit(List<XidInfo> committables) {
        return xaGroupOps
                .commit(
                        new ArrayList<>(committables),
                        false,
                        jdbcConnectionConfig.getMaxCommitAttempts())
                .getForRetry();
    }

    @Override
    public void abort(List<XidInfo> commitInfos) {
        try {
            xaGroupOps.rollback(commitInfos);
        } catch (Exception e) {
            throw new JdbcConnectorException(
                    JdbcConnectorErrorCode.XA_OPERATION_FAILED, "rollback failed", e);
        }
    }
}

View on GitHub (pinned to cf67b549a7)

Solutions

Inspect in-doubt transactions on the database (e.g. Oracle DBA_2PC_PENDING, MySQL XA RECOVER) and resolve them manually (XA COMMIT/ROLLBACK)
Check the wrapped cause for the XA error code to determine whether the connection or the transaction was at fault
Verify connectivity/credentials during failure recovery and re-run the job to trigger XA recovery (recoverCheckpointTransactions)
If transactions were already resolved, this error is benign residue — clean up pending XA entries to stop recurrence

Example fix

// DB-side cleanup example (MySQL)
// before: in-doubt xids left pending
XA RECOVER;
// after
XA ROLLBACK 'xid_bytes_from_xa_recover';

Defensive patterns

Strategy: try-catch

Validate before calling

// before running exactly-once jobs, ensure no pending transactions
// MySQL: XA RECOVER;  Oracle: SELECT * FROM DBA_2PC_PENDING;

Try / catch

try {
  committer.abort(xids);
} catch (JdbcConnectorException e) {
  logger.error("XA rollback failed; check in-doubt transactions on the DB", e);
  // alert operator to manually resolve pending XA transactions
}

Prevention

Periodically check for in-doubt XA transactions on the database
Ensure stable network between SeaTunnel workers and the database during commit/abort
Do not hard-kill workers mid-checkpoint with exactly-once enabled
Grant the job user privileges to inspect/resolve XA transactions

When it happens

Trigger: abort() is invoked when a checkpoint fails or the job is terminated with exactly-once enabled (is_exactly_once=true), and xaGroupOps.rollback throws — e.g. connection lost mid-rollback, XAER_RMERR from the database, or transactions already resolved elsewhere.

Common situations: Database connection dropped after a prepared transaction; DBA manually committed/rolled back in-doubt transactions concurrently; XA timeout on the database side; cluster crash during abort.

Related errors

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/b45ef50ec398c2a1. Report an issue: GitHub.