bazel config fails with no configuration found error

Description of the bug:

I have a constraint named mach, that I use in a select statement. A simplified pseudo code is below

constraint_setting(mach) # values = [ A, B, C]
cc_binary("binary", srcs = select(A = ["a.cpp"], .. )

# 
platform("PA", constraint_values = ["mach:A"])
platform("PB", constraint_values = ["mach:B"])

create_image('IA', deps = ["binary"], platform = "PA")
create_image('IB', deps = ["binary"], platform = "PB")

create_image does a transition on the platform internally.

It works for most of the images, but for some image it fails to build with the an error

configurable attribute "srcs" in mylibname doesn't match this configuration: Unable to find mach implementation for 'servo'
This instance of mylibname has configuration identifier 22f6aa7

But when I try bazel config 22f6aa7, it errors out with

︁︁ ︁ bazel config 22f6aa7
INFO: Invocation ID: c7fa3463-a54c-49ea-bb21-79f8c3717ac2
INFO: Displaying config with id 22f6aa7
ERROR: No configuration found with ID prefix 22f6aa7

I also tried

︁︁ ︁ bazel config
INFO: Invocation ID: 033a5c8a-c369-4616-a4fe-7b6270175228
Available configurations:

Link to the slack discussion https://bazelbuild.slack.com/archives/CA31HN1T3/p1655992434086069

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

No response

Which operating system are you running Bazel on?

Ubuntu 16.04.7 LTS

What is the output of bazel info release?

release 5.0.0- (@non-git)

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

NIXOS based bazel

What’s the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[katre]

Debugging bazel is kind of tricky, but here’s a rough guide:

1. Build a dev version of bazel: in the bazel source tree, run bazel build -c dbg //src:bazel
   1. Test your build with the dev version, just in case
   2. Or use the bazel-dev.sh script from the bazel source: this will rebuild your dev bazel if necessary, assuming that either you checked out bazel to $HOME/os-bazel or that you set the BAZEL_DIR environment attribute
2. Start the dev bazel with debugging: bazel-dev --host_jvm_debug build options targets
   1. This starts the Java process listening on port 5005, and pauses execution until the debugger connects.
3. Attach your debugger. I use IntelliJ (with the Bazel plugin), but any JVM debugger should work. You’ll need to make sure it knows where your Bazel source is, of course.
4. For this, set a breakpoint at SkyframeExecutor.handleAnalysisInvalidatingChange, and see if that works. This might be the wrong location, since I don’t see the log message I would expect.
   1. Other options are SkyframeExecutor.clearAnalysisCache or BlazeWorkspace.clearCaches

Good luck!

[katre]

Yes, if you’re invalidating your build everytime you invoke Bazel, this will happen.

Look into the --stamp flag and the workspace status feature for a more maintainable way to handle this.