Fix #359: configuration-aware cquery hashing

[tinder-maxwellelliott]

Summary

Resolves the symptom called out in #359: under --useCquery, two configured graphs that differ only in per-edge configuration (a cfg = \"exec\" transition, a --platforms swap, a --config=... change, or a --define toggling a select() inside a dep) collapsed to identical hashes and bazel-diff returned an empty impacted set. The cause is in cli/src/main/kotlin/com/bazel_diff/bazel/BazelRule.kt:

rule.configuredRuleInputList.map { it.label }

.map { it.label } discards ConfiguredRuleInput.configurationChecksum, so the per-edge configuration never makes it into the hash.

The fix

• Fold each cquery dep edge's configurationChecksum into the rule-input string via a new separator |, which is not a valid character in a Bazel label ([A-Za-z0-9/._+=,@~-]* plus : between package and target). The encoded form "<label> |<configurationChecksum>" cannot collide with any real input and survives the existing List<String> return type of BazelRule.ruleInputList.
• RuleHasher writes the full encoded string into the transitive hash (so two configured graphs differing only in per-edge configuration now produce distinct parent digests) but splits on | to recover the bare label for allRulesMap / sourceDigests lookups and dep tracking — so the user-visible deps in the generated JSON stay clean.
• Empty-checksum fallback (a known Bazel quirk where cquery's transitions=lite output sometimes omits the checksum) returns the bare label unchanged, preserving pre-Configuration-aware hashing under --useCquery (parity with target-determinator) #359 behaviour for that path.

This is the minimal symptom-fixing slice of #359 — the parent target's hash now reflects per-edge configuration changes, so the empty-impacted set under cquery is gone. Full target-determinator parity (per-(label, configuration) digest entries, bazel config --output=json enumeration, empty-checksum inheritance from the depending target) is intentionally out of scope here: those would change the on-disk JSON schema and deserve a separate design discussion on the issue.

Hash-format implication

This is a hash-format change: hashes generated by this version are not comparable to hashes from earlier versions under --useCquery. That is the intended behaviour — the old hashes were missing the configuration signal. Non-cquery hashes are unaffected.

Tests

Builds on the reproducer test merged in #361:

• Flip the @Ignore off the reproducer (testCqueryRuleInputListDistinguishesConfigurationChecksum_issue359) and drop the two _currentBehaviourBuggy_* companions — the bug they pinned is no longer current.
• Add testCqueryRuleInputListEncodesLabelAndChecksum_issue359 to pin the on-the-wire encoding so the format is observable and future changes are intentional.
• Add testCqueryRuleInputListEmptyChecksumFallsBackToBareLabel_issue359 to cover the Bazel-quirk fallback.
• Add testNonCqueryRuleInputListIgnoresConfiguredRuleInput_issue359 to confirm the encoding does not leak into the non-cquery path.
• Add testDecodeConfiguredRuleInputLabelRoundTrip_issue359 to pin the round-trip behaviour RuleHasher relies on (the bare-label decode is what guards deps from being polluted with |<checksum> suffixes).

Test plan

• bazel test //cli:BazelRuleTest //cli:BuildGraphHasherTest //cli:CalculateImpactedTargetsInteractorTest //cli:CalculateImpactedTargetsInteractorIssue335Test //cli:CalculateImpactedTargetsInteractorModuleQueryTest //cli:SourceFileHasherTest //cli:TargetHashTest //cli:DeserialiseHashesInteractorTest //cli:ModuleGraphParserTest //cli:BazelClientTest //cli:BazelTargetTest — all 11 pass locally.
• CI: full E2E matrix (ubuntu+macos × bazel 7/8/9) — //cli:E2ETest runs the cquery-with-platform-swap fixture (testUseCqueryWithExternalDependencyChange / testUseCqueryWithAndroidCodeChange), which is the e2e equivalent of the reproducer. Local E2E was skipped due to a JDK-sandbox issue unrelated to this change.
• CI: 90% main-source line-coverage gate.

Refs #359, #361

🤖 Generated with Claude Code