apache/hadoop · error · IOException

%s: unknown conflict resolution mode: %s

Error message

%s: unknown conflict resolution mode: %s

What it means

IOException from DirectoryStagingCommitter.cleanupJob's default switch branch when getConflictResolutionMode returns a ConflictResolution value that the switch does not handle. In stock Hadoop the enum only has FAIL, APPEND and REPLACE and the config is parsed with ConflictResolution.valueOf (StagingCommitter:833), so an invalid fs.s3a.committer.staging.conflict-mode string fails earlier with IllegalArgumentException. Reaching this branch therefore means an enum constant exists that the switch was never updated for -- a code/version integrity problem, not a config typo.

Source

Thrown at hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3a/commit/staging/DirectoryStagingCommitter.java:132

    Path outputPath = getOutputPath();
    FileSystem fs = getDestFS();
    Configuration fsConf = fs.getConf();
    switch (getConflictResolutionMode(context, fsConf)) {
    case FAIL:
      // this was checked in setupJob; temporary files may have been
      // created, so do not check again.
      break;
    case APPEND:
      // do nothing
      break;
    case REPLACE:
      if (fs.delete(outputPath, true /* recursive */)) {
        LOG.info("{}: removed output path to be replaced: {}",
            getRole(), outputPath);
      }
      break;
    default:
      throw new IOException(getRole() + ": unknown conflict resolution mode: "
          + getConflictResolutionMode(context, fsConf));
    }
  }
}

View on GitHub (pinned to 2add963021)

Solutions

1. Align hadoop-aws and hadoop-common versions on every node so exactly one ConflictResolution enum is on the classpath
2. If you maintain a fork that adds a conflict mode, add its case to this switch (and the one in PartitionedStagingCommitter)
3. Verify fs.s3a.committer.staging.conflict-mode is one of fail, append, replace (this surfaces earlier as IllegalArgumentException if not)

String mode = fsConf.getTrimmed("fs.s3a.committer.staging.conflict-mode", "append");
if (!Arrays.asList("fail", "append", "replace").contains(mode)) {
  throw new IOException("Invalid conflict mode: " + mode);
}

try {
  committer.cleanupJob(context);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("unknown conflict resolution mode")) {
    // enum/switch skew: audit the classpath for mismatched hadoop-aws jars
    LOG.error("Version skew suspected in staging committer", e);
  }
}

When it happens

Trigger: A custom hadoop-aws build or fork adds a new ConflictResolution constant but does not extend this switch; jars from mismatched Hadoop versions are mixed on the classpath so the enum seen at runtime differs from the one the committer was compiled against.

Common situations: Patched hadoop-aws deployed without recompiling all committer classes; different Hadoop versions shared across distributed classpath nodes.

Related errors

• %s: unknown conflict resolution mode: %s
• E_DEST_EXISTS
• Multipart IO request {sdkRequest} rejected {header}
• Multipart uploads are disabled for the FileSystem, the commi
• Unable to recover task %s

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/63d01ab29c13cd09. Report an issue: GitHub.