apache/flink · error · IOException

Committing file by rename failed: {} to {}

Error message

Committing file by rename failed: {} to {}

What it means

Thrown by the AzureBlobFsRecoverableDataOutputStream Committer when fs.rename(src, dest) throws an IOException while promoting the staging file to its final path during commit(). The original exception is chained as the cause, so the real reason (permissions, lease, throttling) is on the cause, not the message.

Source

Thrown at flink-filesystems/flink-azure-fs-hadoop/src/main/java/org/apache/flink/fs/azurefs/AzureBlobFsRecoverableDataOutputStream.java:287

                if (srcStatus.getLen() != expectedLength) {
                    LOG.error(
                            "The src file {} with length {} does not match the expected length {}",
                            src,
                            srcStatus.getLen(),
                            expectedLength);
                    throw new IOException(
                            "The src file "
                                    + src
                                    + " with length "
                                    + srcStatus.getLen()
                                    + " "
                                    + "does not match the expected length "
                                    + expectedLength);
                }
                try {
                    fs.rename(src, dest);
                } catch (IOException e) {
                    throw new IOException(
                            "Committing file by rename failed: " + src + " to " + dest, e);
                }
            } else if (!fs.exists(dest)) {
                // neither exists - that can be a sign of
                //   - (1) a serious problem (file system loss of data)
                //   - (2) a recovery of a savepoint that is some time old and the users
                //         removed the files in the meantime.
                throw new IOException(
                        "Unrecoverable exception while trying to recover "
                                + recoverable.tempFile());
            }
        }

        @Override
        public void commitAfterRecovery() throws IOException {
            commit();
        }

View on GitHub (pinned to 2f3c205e92)

Solutions

1. Inspect the cause exception in the stack trace to classify permission vs lease vs throttling
2. Retry the commit from the same checkpoint — commits are idempotent (rename overwrites)
3. Grant write+delete permissions and use full account keys or role-based access instead of narrow SAS tokens
4. Enable/raise fs.azure retry configuration for throttling scenarios

try {
    committer.commit();
} catch (java.io.IOException e) {
    // cause chain holds the real rename failure (lease/permission/throttle)
    log.error("Commit rename failed", e.getCause());
    retryCommitWithBackoff(); // rename-overwrite is idempotent
}

When it happens

Trigger: commit()/commitAfterRecovery() where the final rename in ABFS fails: destination blob under a lease, credential lacking delete permission (ABFS rename = copy + delete), path already exists as a directory, or transient Azure errors.

Common situations: SAS token without delete rights; a reader holding a lease on the target blob; storage throttling during mass commit of many checkpoint files.

Related errors

• Unable to recover. Rename operation failed
• Cannot clean commit: Staging file does not exist.
• The src file {} with length {} does not match the expected l
• Unrecoverable exception while trying to recover {}
• Committing file failed, could not rename {} -> {}

AI-assisted analysis of apache/flink@2f3c205e92 (2026-08-14). Data as JSON: /api/errors/2c3a48bbcec33ef5. Report an issue: GitHub.