bazelbuild/bazel · error · RuntimeError

invocation failed: {stderr}

Error message

invocation failed: {stderr}

What it means

Top-level failure in ctexplain's lib: it assembles a cquery command 'deps(<labels>)' plus build flags, runs it through the bazel API, and if the invocation reports failure it raises RuntimeError('invocation failed: ' + decoded stderr). Everything that makes bazel cquery fail surfaces here.

Source

Thrown at tools/ctexplain/lib.py:40

                  build_flags: Tuple[str, ...]) -> Tuple[ConfiguredTarget, ...]:
  """Gets a build invocation's configured targets.

  Args:
    bazel: API for invoking Bazel.
    labels: The targets to build.
    build_flags: The build flags to use.

  Returns:
    Configured targets representing the build.

  Raises:
    RuntimeError: On any invocation errors.
  """
  cquery_args = [f'deps({",".join(labels)})']
  cquery_args.extend(build_flags)
  (success, stderr, cts) = bazel.cquery(cquery_args)
  if not success:
    raise RuntimeError("invocation failed: " + stderr.decode("utf-8"))

  # We have to do separate calls to "bazel config" to get the actual configs
  # from their hashes.
  hashes_to_configs = {}
  cts_with_configs = []
  for ct in cts:
    # Don't use dict.setdefault because that unconditionally calls get_config
    # as one of its parameters and that's an expensive operation to waste.
    if ct.config_hash not in hashes_to_configs:
      hashes_to_configs[ct.config_hash] = bazel.get_config(ct.config_hash)
    config = hashes_to_configs[ct.config_hash]
    cts_with_configs.append(
        ConfiguredTarget(ct.label, config, ct.config_hash,
                         ct.transitive_fragments))

  return tuple(cts_with_configs)

View on GitHub (pinned to e6e199d060)

Solutions

  1. Read the appended stderr — it is bazel's own error (unknown label, bad flag, missing repo) and names the real cause.
  2. Fix the labels/flags ctexplain was given; verify them with a manual 'bazel cquery deps(//your:target)'.
  3. Resolve any workspace issues the stderr reports (bazel sync / fetch) and rerun ctexplain.

Example fix

# before
explain(['//pkg:nonexistent_target'], [])

# after
explain(['//pkg:real_target'], [])  # verify with: bazel cquery 'deps(//pkg:real_target)'
Defensive patterns

Strategy: try-catch

Validate before calling

rc, out, err = run_bazel(['cquery', 'deps(%s)' % ','.join(labels)] + build_flags)
if rc != 0:
    fail_fast('cquery failed; fix labels/flags first: %s' % err)

Try / catch

try:
    cts = get_cts(bazel, labels, flags)
except RuntimeError as e:
    # 'invocation failed: ...' — stderr of bazel is embedded; fix and rerun
    raise

Prevention

When it happens

Trigger: ctexplain run with labels that do not exist, build flags that bazel rejects, a broken workspace (unresolved deps), or a bazel server error — cquery returns non-zero and this error propagates the stderr.

Common situations: Typos in labels passed to ctexplain; incompatible flags between the ctexplain invocation and the workspace's .bazelrc; workspace needing a fetch or having conflicting repository rules.

Related errors


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