Summary

Fixes the issue discussed in #1063.

Salsa "poisons" a fixpoint query when it panics when executing. All subsequent runs of that query within the same revision will panic with a PropagatedPanic. The issue with that approach is that it incorrectly assumed that the only reason a query can panic and be re-executed in the same revision is due to a bug in the query function. However, this is not the case. A query can also panic due to cancellation that isn't followed by a write.

Ideally, we'd remove the poisoning of fixpoint queries all together. But this is likely a more involved change. The challenge here is that we need a way to mark all cycle heads within a failed query as "failed" to avoid that validate_same_iteration incorrectly returns true for a memo that only reference heads from a sub-cycle because we don't traverse cycle heads recursively.

This PR introduces a new cancellation_count (u8) and packs it into the IterationCount (renamed to IterationStamp). A provisional memo can only be reused if both the iteration count and the cancellation count are equal. I used an u8 because that fits into the QueryRevisionExtra padding. Salsa will "poison" the revision when the u8 overflows. That means, Salsa will force-bump the revision in cancel_others if the cancellation count overflowed even if not followed by any writes. This has the downside that Salsa runs the more expensive deep_verify_memo for LOW durability queries during their next fetch. But that should still be cheap and I'd expect overflows to be rare.

Alternatives

Poison revision

The simplest fix here is that we poison the current revision when a query with fixpoint iteration panics. Salsa bumps the revision on the next cancellation. This is by far the simplest change, but it has the downside that we always bump the revision, including panics that are bugs in the query function.

Tracking cycle states in a central location

The main challenge with fixpoint queries is that we have no reliable way to easily evict the state of an entire cycle because the state is stored across different cycle head memos. I had Codex prototype an implementation where the cycle state is stored in a centralized location #1098 but this resulted in a refactor that's way larger than I currently have an appetite for.

However, I do think that reconsidering where and how we store cycle state might be a worthwhile refactor in the future. Not only might it allow us to remove the cycle head poisoning, it may also help reduce memory usage.