Invalid target throws silent error

[mattboardman]

Changing a target name but not updating dependencies to use the new name throws a silent error.

Example

// Package A depends on "//packages/FOO"
ts_library(
    ...
    deps = [
        "//packages/FOO" # the full name of this target is //packages/FOO:FOO
    ]
)

// Package FOO
// Change FOO:FOO to FOO:BAR in BUILD file
ts_library(
    name = "BAR" # used to be FOO
    ...
)

In the above example Package A is now depending on an invalid target after updating the name. This currently throws a silent error and the impacted files output will be blank.

Expected behavior is to throw an error so the user can be aware they have made an invalid change to the dependency graph.

[tinder-maxwellelliott]

@mattboardman I will be adding a test case to our integration tests today to capture this error. Thank you for reporting this

[tinder-maxwellelliott]

Update: I have been playing around locally with possible solutions to this, the issue is that in this scenario changing a deps name does not behave as I would expect. When I run queries on the build graph after the change I see this result for FOO

<?xml version="1.1" encoding="UTF-8" standalone="no"?>
<query version="2">
    <source-file location="/Users/maxwellelliott/Tinder/bazel-diff/integration/BUILD.bazel:4:12" name="//:Foo">
        <visibility-label name="//visibility:private"/>
    </source-file>
</query>

This is very confusing since this target does not exist in the graph, it seems like Bazel falls back to saying that since it is a listed dep it must be a SOURCE_FILE target.

A possible fix for this would be to assert that any source file targets we return match the list of impacted files we are provided given the -m flag. This limits our ability to hash all targets #52 .

I am open to other ideas, I am astounded that Bazel allows this behavior at all

[tinder-maxwellelliott]

@mattboardman I have been talking with others on the Bazel Slack channel and it seems we would need to validate the graph before running bazel-diff, there seems to be no other way of finding these invalid targets. You will need to run something like:

bazel build --nobuild //... --host_jvm_args -Xmx10240m

I know that this is not a real solution and is memory constrained. I will need to investigate further on how we can find out if a graph is invalid.

[tinder-maxwellelliott]

I have reproduced this in our build, will continue to investigate when I can

[tinder-maxwellelliott]

Potentially cquery can fix this, looking into that now

[tinder-maxwellelliott]

@mattboardman I think I have a solution for this here #76