apache/beam · error · UnsupportedOperationException

Unexpected StandardResolveOptions %s

Error message

Unexpected StandardResolveOptions %s

What it means

HadoopResourceId.resolve() only supports RESOLVE_DIRECTORY and RESOLVE_FILE among StandardResolveOptions; any other option triggers an UnsupportedOperationException. It signals that the requested resolve mode has no Hadoop-URI equivalent.

Source

Thrown at sdks/java/io/hadoop-file-system/src/main/java/org/apache/beam/sdk/io/hdfs/HadoopResourceId.java:55

  HadoopResourceId(URI uri) {
    this.uri = uri;
  }

  @Override
  public ResourceId resolve(String other, ResolveOptions resolveOptions) {
    checkState(
        isDirectory(), String.format("Expected this resource is a directory, but had [%s].", uri));
    if (resolveOptions == StandardResolveOptions.RESOLVE_DIRECTORY) {
      if (!other.endsWith("/")) {
        other += "/";
      }
      return new HadoopResourceId(uri.resolve(other));
    } else if (resolveOptions == StandardResolveOptions.RESOLVE_FILE) {
      checkArgument(!other.endsWith("/"), "Resolving a file with a directory path: %s", other);
      return new HadoopResourceId(uri.resolve(other));
    } else {
      throw new UnsupportedOperationException(
          String.format("Unexpected StandardResolveOptions %s", resolveOptions));
    }
  }

  @Override
  public ResourceId getCurrentDirectory() {
    return new HadoopResourceId(uri.getPath().endsWith("/") ? uri : uri.resolve("."));
  }

  @Override
  public boolean isDirectory() {
    return uri.getPath().endsWith("/");
  }

  @Override
  public String getFilename() {
    if (isDirectory()) {
      Path parentPath = new Path(uri).getParent();

View on GitHub (pinned to 12126d8942)

Solutions

1. Use only StandardResolveOptions.RESOLVE_DIRECTORY or RESOLVE_FILE when resolving against HadoopResourceId.
2. Check the Beam SDK version alignment: if using a newly added resolve option, upgrade the hadoop-file-system module or avoid it for Hadoop-based resource IDs.
3. Wrap resolve calls to validate the option and fall back to RESOLVE_DIRECTORY semantics where appropriate.

checkArgument(resolveOption == StandardResolveOptions.RESOLVE_DIRECTORY || resolveOption == StandardResolveOptions.RESOLVE_FILE, "Unsupported resolve option: %s", resolveOption);

null

try { return resourceId.resolve(child, option); } catch (UnsupportedOperationException e) { return resourceId.resolve(child, StandardResolveOptions.RESOLVE_DIRECTORY); }

When it happens

Trigger: Calling resourceId.resolve(child, someStandardResolveOption) with an option other than RESOLVE_DIRECTORY or RESOLVE_FILE — currently no third option exists in the standard enum, so this is effectively defensive/unreachable except via nonstandard or future options.

Common situations: Custom FileSystems/matchers passing their own resolve options; code written against a newer Beam API introducing a new StandardResolveOptions constant but running against this HadoopResourceId implementation; generic filesystem abstraction layers forwarding unknown options.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Failed to validate %s
• Failed to validate %s
• +fieldType.getTypeName()+ is not supported
• %s.verifyCompatibility() should never be called. It is a pri
• %s.getSideInputWindow() should never be called. It is a priv

AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/5ed03bfafc3c0eee. Report an issue: GitHub.