Increment iteration count for all queries with cycle handling participating in a cycle #1017
+73
−54
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an alternative, and I think a more footgun-proof fix for #1014
Up to now, Salsa increments the iteration count for all cycle heads participating in a query before starting a new iteration. However, queries with cycle handling that aren't cycle heads never increment their iteration count. Instead, they always use zero (or the iteration count from the last iteration).
However, we use the iteration count in multiple places (e.g.
validate_same_iteration,validate_provisional) to assert whether the most recent memo for a given key is "the same" as when a query dependent on it. For this to work, it's essential that the iteration count uniquely identify a query execution, which isn't the case now.The way #1014 works around this is by adding an extra check to
validate_same_iterationthat always skips if a query has become a non-cycle head. This works, but it always requires remembering to check both the iteration count and whether the query is still in the cycle heads. In fact, we currently don't perform this check withinvalidate_provisionalbecause we can't; the cycle heads of a finalized memo are often empty. I'm not sure if that's the cause of the flaky test failures but it might as well be.This PR ensures that salsa either:
Test plan
I tested that the regression test from #1014 still passes and I ran the parallel tests with 10k iterations