Florian Jetter

I replaced the nanny with a simple Worker which is much faster since it doesn't require us to start a process. This _should_ be sufficient

My above analysis was wrong. The test logic is flawed. It prepares all shuffle input data on worker A but expected transfer tasks to be scheduled on worker B. That's...

I slightly rewrote the test. I also confirmed that this test triggers the deadlock condition of https://github.com/dask/distributed/issues/8088 which was the original issue this test was introduced for

> From what I understand, this mechanism works slightly different from what is described here. If a task completes and the size of its output data is above target, we...

@JaccoVE can you please share more information about your problem? Ideally, please open a new issue since there may be many different reasons why such a connection failure occurs and...

It might be necessary / helpful to first deal with https://github.com/dask/dask/issues/11234

As a first step for this I would like to understand how much of the P2P rechunk logic can be reused

What browser are you using for this? - chrome and firefox redirect this to a google search for me - Safari tells me this is not a valid URL and...

I'm not familiar with ngrok so I can't tell what's going on in your case. The way I think the original exception was triggered is that the browser connected to...

The current mechanism is to "gracefully downscale" a worker. This typically evicts all data and runnable tasks but is not waiting for the current one to finish. Instead of using...