Post-sync backup cannot determine completion because source,

Error message

Post-sync backup cannot determine completion because source, staging, and backup target are absent; operation will be retried: splitId={}, source={}, target={}, checkpointId={}

What it means

This WARN fires in commitBackupOperation() when neither the source file, the staging file, nor the backup target can be found on the source filesystem, so the enumerator cannot tell whether the backup already completed or was lost. It returns FAILED_RETRYABLE and waits for a later checkpoint. It usually means the underlying file vanished mid-operation (external deletion, FS inconsistency) or the operation state points at paths that no longer exist.

Source

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

                            op.getSourceLength(),
                            op.getSourceModificationTime());
                    return OpCommitResult.SUCCESS;
                }
                log.error(
                        "Post-sync backup recovery found an inconsistent target; operation will be "
                                + "retried without deleting data: splitId={}, source={}, target={}, "
                                + "capturedLen={}, capturedMtime={}, actualLen={}, actualMtime={}",
                        op.getSplitId(),
                        maskUriUserInfo(op.getSourcePath()),
                        maskUriUserInfo(op.getBackupTargetPath()),
                        op.getSourceLength(),
                        op.getSourceModificationTime(),
                        targetStatus.getLen(),
                        targetStatus.getModificationTime());
                return OpCommitResult.FAILED_RETRYABLE;
            }
            if (stagingStatus == null) {
                log.warn(
                        "Post-sync backup cannot determine completion because source, staging, and "
                                + "backup target are absent; operation will be retried: splitId={}, "
                                + "source={}, target={}, checkpointId={}",
                        op.getSplitId(),
                        maskUriUserInfo(op.getSourcePath()),
                        maskUriUserInfo(op.getBackupTargetPath()),
                        checkpointId);
                return OpCommitResult.FAILED_RETRYABLE;
            }
        }

        if (targetStatus != null && sourceStatus != null) {
            // Never use an existing target as proof that this source can be deleted: it may belong
            // to a previous attempt while a writer has recreated the source path.
            log.warn(
                    "Post-sync backup skipped because target already exists; source is retained: "
                            + "splitId={}, source={}, target={}, checkpointId={}",
                    op.getSplitId(),

View on GitHub (pinned to cf67b549a7)

Solutions

Check whether an external cleanup/TTL job deletes files from the source or backup directories and exclude the in-flight paths
Verify filesystem consistency (especially S3/OSS eventual consistency) and that the paths in the log actually exist
Compare the checkpoint state (sourcePath/backupTargetPath) against the live filesystem to confirm the paths are correct
If the file was legitimately deleted externally, clear the stale operation state or restart the job so it re-discovers files

Example fix

null

Defensive patterns

Strategy: retry

Validate before calling

// Pre-check that at least one of source/staging/target exists before committing
boolean anyPresent = fs.exists(sourcePath) || fs.exists(stagingPath) || fs.exists(targetPath);
if (!anyPresent) {
    // surface loudly instead of silently retrying forever
    throw new IllegalStateException("All backup paths absent for split " + splitId);
}

Try / catch

try {
    OpCommitResult r = enumeratorCommit(op);
} catch (java.io.IOException e) {
    // FAILED_RETRYABLE semantics: bound the retries, alert if exceeded
    if (++attempts > MAX_ATTEMPTS) alertOperator(op, e);
}

Prevention

Exclude source/staging/backup directories from external TTL/cleanup jobs
Run only one job instance per source path; use unique staging paths per job
Verify object-store consistency behavior before enabling post-sync backup on S3/OSS

When it happens

Trigger: During checkpoint commit, getFileStatusIfPresent() returns null for op.getSourcePath(), the staging path, AND op.getBackupTargetPath() — i.e. all three paths are absent from the source filesystem.

Common situations: An external process (cleanup job, TTL policy, another pipeline) deleted the source file while the backup was in flight; object-store eventual-consistency hiding recently renamed files; operator state from a failed attempt whose staging and target were already removed.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

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