Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix rule graph nondeterminism due to undetected ambiguity #7379

Merged
merged 6 commits into from Mar 14, 2019

Conversation

Projects
None yet
4 participants
@stuhood
Copy link
Member

commented Mar 14, 2019

Problem

Integration tests of @console_rules would frequently flake (as in #6782) with rules self-cycling in a peculiar way. Investigating the failure lead to the conclusion that the RuleGraph was being constructed non-deterministically.

The source of the non-determinism was that we were "simplifying" all instances of one @rule that used the same number of Params, and treating them interchangeably. But that simplification was subject to rust's randomized hash ordering, and so we would choose which of the Params to use at random.

After fixing that non-determinism, we also needed to solve the underlying ambiguities (there were two or three) that lead to there being multiple options to choose from.

Solution

  • Change GraphMaker::choose_dependency to not simplify rules, and instead preserve all candidates with the current minimum Param set size.
  • Fix the ambiguity that lead to multiple choices being available by introducing an (intuitive, I think) restriction that only subgraphs that actually use the Param provided by a Get are eligible to satisfy it. See the explanation in the test.

Result

Unskips @console_rule integration tests, and adds a (previously flaky, now stable) unit test of the ambiguous case. Fixes #6782.

stuhood added some commits Mar 12, 2019

Avoid `simplifying` rules while choosing a non-ambiguous source of a …
…dep. Otherwise, we will not detect the case where the same rule can be satisfied by multiple parameter combinations.
Add the constraint that we will only consider a rule to be satisfiabl…
…e if it consumes a provided Get param (possibly transitively).
@stuhood

This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2019

Individual commits are useful to review independently.

@illicitonion
Copy link
Contributor

left a comment

Thanks!

@ity

ity approved these changes Mar 14, 2019

Copy link
Contributor

left a comment

lgtm!

let mut rules_by_kind: HashMap<EntryWithDeps, (usize, &Entry)> = HashMap::new();
for satisfiable_entry in &satisfiable_entries {
// We prefer the non-ambiguous rule with the smallest set of Params, as that minimizes Node
// identities in the graph and biases toward receiving values from dependencies (which do not

This comment has been minimized.

Copy link
@ity

ity Mar 14, 2019

Contributor

s/identifies/selections?

This comment has been minimized.

Copy link
@stuhood

stuhood Mar 14, 2019

Author Member

This is "identities", which is accurate here... we refer to the Params that a @rule consumes as part of its "identity", because the same @rule can be used with multiple sets of Params, which might each (as seen in this ticket!) affect their behaviour.

@blorente
Copy link
Contributor

left a comment

I don't have enough context for any meaningful comments. Will read through it tomorrow but would not like to block it.

Fix `test_get_type_match_failure`, which was not actually consuming `…
…nested_raise` (because it was not installed).

@stuhood stuhood merged commit eae7035 into pantsbuild:master Mar 14, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@stuhood stuhood deleted the twitter:stuhood/rule-graph-nondeterminism branch Mar 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.