Ensure reconnecting workers do not loose required data #5436
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.
Again a deadlock masked by mark.repeat flags. We should be more careful with these flags. This time, at least, this showed up as AssertionErrors in tests
If a worker briefly disconnects it has the chance to register what tasks it already has in memory and is currently executing. If it has data which is already released, it is also asked to release this. However, this introduces a subtle race condition where the worker is asked to release all it's data although we simultaneously would expect him to compute that keys dependent. Therefore, we should use the safe handler (remove-replica) instead of the strict handler (free-keys). See comment below for the proper section.
I took this chance to clean up the signature around free-keys to be in alignment with the rest
test_worker_reconnects_mid_compute_multiple_states_on_scheduler
flaky #5377