I believe build failures are unrelated. There is one failure connected to work stealing on Windows Python3.7 but so far I couldn't reproduce this. Maybe flaky? Are there tests known to be flaky in the test_stealing.py module?

I added the prefix.name patch to the line you mentioned but I couldn't add a test for it. In fact, I would argue it is unreachable code since the only place where we populate this dictionary is

but this line assumes that ts.processing_on is None which is an invalid state since all stealing dicts are only populated for tasks in state processing and as soon as a task is transitioned away from processing we'll remove it from stealable.
Is there something I'm missing? Can this be removed? (Other PR, of course)

If this is true then yes, it would be good to remove this code. It might be worth checking out git blame to see why this was added in the first place, and spot checking the various ways in which tasks can be removed from the processing state to make sure that we're not missing any stealable cleanups.

Thank you for identifying and resolving this issue @fjetter . I imagine that it was not trivial to track down.

If this is true then yes, it would be good to remove this code. It might be worth checking out git blame to see why this was added in the first place

I'll try to investigate the history and come back with what I find.

I imagine that it was not trivial to track down.

Indeed, this one was uncomfortable. We do not really instrument the work stealing which made me fall back to "watching dashboards", greping logs and pulling scheduler/workerr state with client.run*. I this particular case a mere "unique prefixes which were subject to stealing" would've shown the issue already but I suspect this is worthless in most other scenarios. I'm wondering if it's worth collecting things like average steal_time_ratio per task/taskprefix, total count of stolen tasks, most likely victims / thieves, etc. Has this issue ever come up somewhere else?

Thanks @fjetter . This is in.