Skip to content

--useCquery still drops main-repo aliases in WORKSPACE mode (follow-up to #612) - #622

Open
bala-evani-ai wants to merge 2 commits into
Tinder:masterfrom
bala-evani-ai:fix-workspace-mode-main-repo-alias
Open

bala-evani-ai wants to merge 2 commits into
Tinder:masterfrom
bala-evani-ai:fix-workspace-mode-main-repo-alias

Conversation

@bala-evani-ai

@bala-evani-ai bala-evani-ai commented Nov 4, 2026 •

Copy link
Copy Markdown

Thanks for the quick fix in #617! It works for Bzlmod, but WORKSPACE mode it doesn't and hit the same bug there: with --useCquery, a change behind a main-repo alias never reaches the targets that use it.

Repro

I added a WORKSPACE-mode copy of the #612 fixture (cquery_main_repo_alias_workspace). It's the same //:wrapper → //:tool (alias) → //bar:baz graph, plus a WORKSPACE file and a .bazelrc with --noenable_bzlmod --enable_workspace, like hub_spoke_external.

With 74.0.1 on Bazel 8.8.2, after changing bar/baz.txt:

  • query mode: //:tool, //:wrapper, //:wrapper.txt, //bar:baz, //bar:baz.txt are impacted, as expected
  • --useCquery: only //bar:baz and //bar:baz.txt. //:tool isn't in the hash file at all.

Why it still happens

#617 turns the alias name from repr() (//:tool) into @@//:tool. That matches Bzlmod, where --consistent_labels prints main-repo targets as @@//.... In WORKSPACE mode it prints them with a single @ instead (@//:wrapper), so @@//:tool still doesn't match and the alias gets filtered out as incompatible.

Running --consistent_labels with a small Starlark formatter on the fixture shows it:

WORKSPACE:  repr=<alias target //:tool of //bar:baz>  str(label)=@//bar:baz   repo_name=""
Bzlmod:     repr=<alias target //:tool of //bar:baz>  str(label)=@@//bar:baz  repo_name=""

All three forms (//x, @//x, @@//x) refer to the same main-repo target; only the prefix differs by mode.

The fix

Instead of guessing the prefix in the Starlark formatter, this compares labels with the main-repo prefix stripped. A new main_repo_label_key() maps //x, @//x and @@//x to //x and leaves external labels alone. It's used both when building the compatible set and when checking targets against it. That's in line with how is_main_repo / main_repo_path in src/hash.rs already treat these.

I looked at fixing it in Starlark instead, but Label() isn't available in the cquery dialect, and target.label on an alias gives you the actual target, not the alias.

Tests

Like #617, the reproducer and the fix are separate commits.

… under --useCquery

Adds cquery_main_repo_alias_workspace, the cquery_main_repo_alias graph run
with --noenable_bzlmod --enable_workspace, and an e2e case asserting that a
change behind the alias reaches //:wrapper under --useCquery. It fails on
master: in WORKSPACE mode main-repository labels print as @//, not @@//.
…ne form

The Tinder#612 fix prefixed the apparent label repr() gives a main-repository
alias (//:tool) with @@, the main repository's canonical form under Bzlmod.
In WORKSPACE mode --consistent_labels prints main-repository targets as
@//:tool, so @@//:tool still never matched, and the alias was dropped as if
it were platform-incompatible, together with every edge through it.

Compare the compatible-target labels through main_repo_label_key, which
maps //x, @//x and @@//x to //x and leaves external labels alone, instead of
guessing the prefix in the cquery formatter.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant