Post-sync backup promotion target is absent after rename; op

Error message

Post-sync backup promotion target is absent after rename; operation will be retried: splitId={}, source={}, target={}, checkpointId={}

What it means

This WARN fires when the final promotion rename (staging -> backup target) appears to succeed but a subsequent getFileStatus on the backup target path returns null, meaning the promoted file cannot be seen. The operation returns FAILED_RETRYABLE. It typically reflects object-store eventual consistency, a lost rename, or something deleting the target right after promotion.

Source

Thrown at seatunnel-connectors-v2/connector-file/connector-file-base/src/main/java/org/apache/seatunnel/connectors/seatunnel/file/source/split/ContinuousMultipleTableFileSourceSplitEnumerator.java:935

                    maskUriUserInfo(stagingPath),
                    checkpointId);
            return OpCommitResult.FAILED_RETRYABLE;
        }

        if (!isOperationContentMatched(ctx, op, stagingPath, stagingStatus)) {
            return handleStaleStagedOperation(
                    ctx, op, checkpointId, stagingPath, "backup", stagingStatus);
        }

        if (!isSinkTargetCommitted(ctx, op, checkpointId, stagingPath)) {
            return handleRetryableStagedOperation(
                    ctx, op, checkpointId, stagingPath, "backup", stagingStatus);
        }

        ctx.sourceFs.renameFile(stagingPath, op.getBackupTargetPath(), false);
        targetStatus = getFileStatusIfPresent(ctx.sourceFs, op.getBackupTargetPath());
        if (targetStatus == null) {
            log.warn(
                    "Post-sync backup promotion target is absent after rename; operation will be retried: "
                            + "splitId={}, source={}, target={}, checkpointId={}",
                    op.getSplitId(),
                    maskUriUserInfo(op.getSourcePath()),
                    maskUriUserInfo(op.getBackupTargetPath()),
                    checkpointId);
            return OpCommitResult.FAILED_RETRYABLE;
        }
        if (!isOperationContentMatched(ctx, op, op.getBackupTargetPath(), targetStatus)) {
            log.warn(
                    "Post-sync backup promoted an unexpected target version; operation will be retried: "
                            + "splitId={}, source={}, target={}, checkpointId={}",
                    op.getSplitId(),
                    maskUriUserInfo(op.getSourcePath()),
                    maskUriUserInfo(op.getBackupTargetPath()),
                    checkpointId);
            return OpCommitResult.FAILED_RETRYABLE;
        }

View on GitHub (pinned to cf67b549a7)

Solutions

Verify the backup target path in the log exists via an independent client (hdfs dfs -ls / aws s3 ls)
Check for cleanup jobs racing on the backup directory and exclude the in-flight target
If on an eventually-consistent object store, rely on the built-in retry at the next checkpoint rather than manual action
Check filesystem/rename implementation health (NameNode logs, S3 error rates) around the timestamp of the warning

Example fix

null

Defensive patterns

Strategy: retry

Validate before calling

// Post-rename verification in your own pipelines:
FileStatus t = fs.getFileStatus(targetPath); // throws FileNotFoundException if lost
if (t == null || t.getLen() != expectedLen) { retryOrAlert(); }

Try / catch

try {
    fs.renameFile(staging, target, false);
    if (fs.getFileStatus(target) == null) { retryWithBackoff(); }
} catch (IOException e) {
    retryWithBackoff();
}

Prevention

Independently verify promoted files with an out-of-band client after backups
Exclude backup directories from TTL/cleanup jobs
Accept the built-in retry-on-next-checkpoint behavior for eventual-consistency lag

When it happens

Trigger: ctx.sourceFs.renameFile(stagingPath, op.getBackupTargetPath(), false) completes without exception, then getFileStatusIfPresent(ctx.sourceFs, op.getBackupTargetPath()) returns null.

Common situations: S3/OSS/Azure eventual-consistency lag right after rename; backup target path cleaned by a TTL job seconds after promotion; filesystem outage dropping the rename silently; wrong bucket/container permissions letting the rename be a no-op wrapper.

Related errors

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