Failed to evaluate recovered split {}, re-enqueue it conserv

Error message

Failed to evaluate recovered split {}, re-enqueue it conservatively.

What it means

When recovering splits from a checkpoint, the enumerator calls context.shouldProcess(sourceStatus, jobStartTimeMillis, startMode) to decide whether a recovered split still needs processing. If that evaluation throws an IOException (e.g. probing file status fails), it logs this warning and conservatively sets shouldProcess = true, so the split is re-enqueued and reprocessed rather than skipped. This favors reprocessing over data loss.

Source

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

            FileStatus sourceStatus;
            try {
                sourceStatus = context.sourceFs.getFileStatus(split.getFilePath());
            } catch (IOException e) {
                if (log.isDebugEnabled()) {
                    log.debug(
                            "Skip recovering split because source file status cannot be resolved: {}",
                            maskUriUserInfo(split.getFilePath()),
                            e);
                }
                skipped++;
                continue;
            }

            boolean shouldProcess;
            try {
                shouldProcess = context.shouldProcess(sourceStatus, jobStartTimeMillis, startMode);
            } catch (IOException e) {
                log.warn(
                        "Failed to evaluate recovered split {}, re-enqueue it conservatively.",
                        maskUriUserInfo(split.getFilePath()),
                        e);
                shouldProcess = true;
            }
            if (!shouldProcess) {
                skipped++;
                continue;
            }

            synchronized (lock) {
                pendingSplits.addLast(split);
                pendingSplitIds.add(split.splitId());
                SplitVersion splitVersion = SplitVersion.fromFileStatus(sourceStatus);
                pendingSplitVersions.put(split.splitId(), splitVersion);
                knownSplitVersions.put(split.splitId(), splitVersion);
            }
            recovered++;

View on GitHub (pinned to cf67b549a7)

Solutions

Fix the underlying filesystem error shown in the logged exception
Expect possible duplicate reprocessing of the affected splits; ensure downstream can tolerate or deduplicate re-reads
Verify source paths referenced by the checkpoint still exist before restarting the job

Defensive patterns

Strategy: retry

Validate before calling

// Before restoring, confirm all checkpointed split source files still exist
for (FileSourceSplit s : recoveredSplits) {
    if (!fs.exists(s.getFilePath())) {
        log.warn("Recovered split source missing: {}", s.getFilePath());
    }
}

Try / catch

try {
    shouldProcess = context.shouldProcess(sourceStatus, jobStartTimeMillis, startMode);
} catch (IOException e) {
    log.warn("Failed to evaluate recovered split {}, re-enqueue it conservatively.",
            maskUriUserInfo(split.getFilePath()), e);
    shouldProcess = true;
}

Prevention

Verify source files referenced by checkpoints still exist before restarting
Restore only on a healthy filesystem connection
Design downstream sinks to deduplicate re-read data, since conservative re-enqueue may reprocess files

When it happens

Trigger: recoverSplitsFromCheckpoint processing a split whose source file status cannot be evaluated — the file or its directory is temporarily inaccessible, or the filesystem throws while checking status/paths needed by shouldProcess.

Common situations: Restart from checkpoint while the source filesystem is degraded; files deleted between checkpoint and recovery; transient FS errors at job recovery time.

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/e4148d0df027d650. Report an issue: GitHub.