bazelbuild/bazel · error · Undefined

%s is experimental and thus unavailable with the current fla

Error message

%s is experimental and thus unavailable with the current flags. It may be enabled by setting --%s

What it means

Raised during module resolution when a predeclared name exists but is wrapped in a FlagGuardedValue.onlyWhenExperimentalFlagIsTrue guard and the corresponding semantics flag is disabled. The name resolves (spelling is right) but access is refused, and the message tells you exactly which --flag enables it. This surfaces as a resolution error ('name ... is experimental ...'), not an EvalException at call time.

Source

Thrown at src/main/java/net/starlark/java/eval/Module.java:273

      }
    }
    return m.buildOrThrow();
  }

  /** Implements the resolver's module interface. */
  @Override
  public Resolver.Scope resolve(String name, boolean resolveTypeSyntax) throws Undefined {
    // global?
    if (globalIndex.containsKey(name)) {
      return Resolver.Scope.GLOBAL;
    }

    // predeclared?
    Object v = getPredeclared(name);
    if (v != null) {
      if (v instanceof GuardedValue) {
        // Name is correctly spelled, but access is disabled by a flag or by client data.
        throw new Undefined(((GuardedValue) v).getErrorFromAttemptingAccess(name));
      }
      return Resolver.Scope.PREDECLARED;
    }

    // universal?
    if (Starlark.UNIVERSE.containsKey(name)) {
      return Resolver.Scope.UNIVERSAL;
    }
    if (resolveTypeSyntax && Starlark.UNIVERSE_EXTRA_TYPE_CONSTRUCTORS.containsKey(name)) {
      return Resolver.Scope.UNIVERSAL;
    }

    // undefined
    Set<String> candidates = new HashSet<>();
    candidates.addAll(globalIndex.keySet());
    candidates.addAll(predeclared.keySet());
    candidates.addAll(Starlark.UNIVERSE.keySet());
    if (resolveTypeSyntax) {

View on GitHub (pinned to e6e199d060)

Solutions

1. Add the flag named in the message to the Bazel invocation: bazel build --experimental_<flag> //... (or via .bazelrc).
2. Guard usage in the .bzl so the symbol is only referenced when the semantics allow it (check hasattr-style probing or flag-guarded branches).
3. If the flag cannot be enabled in your environment, stop using the experimental symbol and use the stable equivalent.
4. Pin/align the Bazel version between local and CI so flag sets match.

Example fix

# before (fails: symbol is experimental)
kind = type(x)

# after: enable the flag in .bazelrc
# build --experimental_enable_starlark_set
kind = type(x)

# in .bazelrc or invocation, enable the flag named in the error:
# build --experimental_<name_of_flag>

When it happens

Trigger: Referencing a builtin whose definition is wrapped by StarlarkSemantics-dependent experimental flags, e.g. type() behind --experimental_enable_starlark_set or an experimental rule/builtin behind --experimental_..., without passing that flag on the Bazel/server command line.

Common situations: Using a freshly documented experimental Starlark feature in .bzl files while the build runs with default flags; a repo tool bump that newly guards a previously open symbol; CI using different bazel flags than the developer's workstation.

Related errors

• This converter doesn't support Starlark reversal.
• Invalid options syntax: %s Note: Negative target patterns ca
• %s is deprecated and will be removed soon. It may be tempora
• name '%s' is not defined
• Unsupported JUnit Runner API version ${JUNIT_API_VERSION_PRO

AI-assisted analysis of bazelbuild/bazel@e6e199d060 (2026-08-14). Data as JSON: /api/errors/7a9c2bc98c61d37a. Report an issue: GitHub.