Build failure caused by no-op starlark transition (friction between Starlark None and java null)

Description of the problem / feature request:

Our fuzzing rules library implements a Starlark transition to provide compiler instrumentation options when building fuzz test executables. In order to reduce build size output, we would like to provide a “no-op” mode in which the transition is disabled through a bool config flag and the parent configuration is passed through unchanged.

However, when we attempt a build in this “no-op” transition configuration, we’re hitting build failures of the form:

ERROR: file 'external/re2/_objs/re2/rune.pic.o' is generated by these conflicting actions:
Label: @re2//:re2
RuleClass: cc_library rule
Configuration: 3c05312acc4ad4afcdf2f011f312660ad214f21abaa06671cad80d482163789b, 2e241eb8731382b18fcb12c9a4b7eb174abce65a2e229b9754f25836277ec281
Mnemonic: CppCompile
Action key: e064b11b5c25436d8c57c05d4e04baa44c8de4fdc572c688519590053b2a3df1
Progress message: Compiling util/rune.cc
PrimaryInput: File:[/usr/local/google/home/sbucur/.cache/bazel/_bazel_sbucur/2527f57e21cfbf2e414b894f7610e705/external/re2[source]]util/rune.cc
PrimaryOutput: File:[[<execution_root>]bazel-out/k8-fastbuild/bin]external/re2/_objs/re2/rune.pic.o
Owner information: ConfiguredTargetKey{label=@re2//:re2, config=BuildConfigurationValue.Key[3c05312acc4ad4afcdf2f011f312660ad214f21abaa06671cad80d482163789b]}, ConfiguredTargetKey{label=@re2//:re2, config=BuildConfigurationValue.Key[2e241eb8731382b18fcb12c9a4b7eb174abce65a2e229b9754f25836277ec281]}
MandatoryInputs: are equal
Outputs: are equal
ERROR: com.google.devtools.build.lib.skyframe.ArtifactConflictFinder$ConflictException: com.google.devtools.build.lib.actions.MutableActionGraph$ActionConflictException: for external/re2/_objs/re2/rune.pic.o, previous action: action 'Compiling util/rune.cc', attempted action: action 'Compiling util/rune.cc'

Running bazel config on the two configuration yields the following:

$ bazel config 3c05312acc4ad4afcdf2f011f312660ad214f21abaa06671cad80d482163789b 2e241eb8731382b18fcb12c9a4b7eb174abce65a2e229b9754f25836277ec281
INFO: Displaying diff between configs 3c05312acc4ad4afcdf2f011f312660ad214f21abaa06671cad80d482163789b and 2e241eb8731382b18fcb12c9a4b7eb174abce65a2e229b9754f25836277ec281
Displaying diff between configs 3c05312acc4ad4afcdf2f011f312660ad214f21abaa06671cad80d482163789b and 2e241eb8731382b18fcb12c9a4b7eb174abce65a2e229b9754f25836277ec281
FragmentOptions user-defined {
  @rules_fuzzing//fuzzing:cc_engine_instrumentation: none, null
  @rules_fuzzing//fuzzing:cc_engine_sanitizer: none, null
  @rules_fuzzing//fuzzing:cc_fuzzing_build_mode: false, null
}

The only differences in config seem to be related to input configs in the transition that we only read and not list in the output.

The transition is defined as follows:

fuzzing_binary_transition = transition(
    implementation = _fuzzing_binary_transition_impl,
    inputs = [
        "@rules_fuzzing//fuzzing:cc_engine_instrumentation",
        "@rules_fuzzing//fuzzing:cc_engine_sanitizer",
        "@rules_fuzzing//fuzzing:cc_fuzzing_build_mode",
        "//command_line_option:copt",
        "//command_line_option:conlyopt",
        "//command_line_option:cxxopt",
        "//command_line_option:linkopt",
    ],
    outputs = [
        "//command_line_option:copt",
        "//command_line_option:conlyopt",
        "//command_line_option:cxxopt",
        "//command_line_option:linkopt",
    ],
)

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

$ git clone [e-mail]:bazelbuild/rules_fuzzing.git -b no-op-transitions
$ cd rules_fuzzing
$ bazel test //examples/...

What operating system are you running Bazel on?

Debian-based Linux.

What’s the output of bazel info release?

release 4.0.0

Have you found anything relevant by searching the web?

This issue seems to be loosely related to conversations in #11196.

[gregestren]

FYI I know I owe you more responses on your recent input…

[fmeum]

Got it. #12888 (comment) makes a lot of sense. As you stated it it sounds like a no-brainer. I’ll continue discussion on #13971.

Re: no-op transitions specifically, would 11f2540 help? The intent was to make no-op transitions more user-friendly and performant: basically provide a simple UI early-return bypass.

I don’t know offhand if that code kicks in before the default setting changes you mention. I’d like to think so but I’m not sure. Nothing a quick review through the code couldn’t clarify. 😃

Unfortunately that shortcut doesn’t help: It applies at a point where defaults have already been added to fromOptions since this is already done in ConfigurationResolver. I verified that I also get action conflicts. The problem seems to have little to do with what the transition does, only with its declared input and output build settings.