Add tests for cancellation in fixpoints

[Veykril]

revision_bump_clears_poisoned_memo replicates the issue discussed in #1063

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	a3590b7
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/69e09fdd6f025b000845aba4

[MichaReiser]

I guess we have the same problem when someone calls trigger_cancellation, since it doesn't bump a new revision either.

[Veykril]

Yea, both of those have the same issue. We don't really need to merge this right now, just put this up so I don't lose it. So yea, unsure what we wanna do here, either we need to remove these functions (which would be a shame, their point is that they do not bump the revision), or we need to figure out how to handle poisoning differently. In r-a we'll avoid calling these for now as the gain from their use is marginal.

[MichaReiser]

What makes cycle recovery tricky is that there's no guarantee that queries will be executed in the same order after they've been cancelled. E.g., if we have a -> b -> a ' and the query gets canceled, there's a chance that the execution plan now is executed b -> a -> b`.

A possibility is to walk the entire dependency tree and nuke all memos.

[Veykril]

You mean the plan changes the next time someone enters the cycle? What would be the issue with it changing?

[MichaReiser]

You mean the plan changes the next time someone enters the cycle? What would be the issue with it changing?

Yes, because the user calls a different root query.

The issue with it is that it requires invalidating all provisional memoized values that participated in the query because the iteration count isn't sufficient to distinguish a provisional memoized value that was computed when entering from a from one computed when entering from b (and the values from iteration 2 could be different dependend on what the root query is)