You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
map_overlap tasks fail to deserialize on workers - keywords must be strings #6624
2022-06-23 19:16:55,060 - distributed.core - ERROR - keywords must be strings
Traceback (most recent call last):
File "/Users/gabe/dev/distributed/distributed/core.py", line 849, in handle_stream
handler(**merge(extra, msg))
File "/Users/gabe/dev/distributed/distributed/worker.py", line 1818, in _
event = cls(**kwargs)
File "<string>", line 13, in __init__
File "/Users/gabe/dev/distributed/distributed/worker_state_machine.py", line 667, in __post_init__
self.run_spec = SerializedTask(**self.run_spec) # type: ignore[unreachable]
TypeError: keywords must be strings
...
2022-06-23 19:16:55,068 - distributed.nanny - ERROR - Worker process died unexpectedly
self._target(*self._args, **self._kwargs)
File "/Users/gabe/dev/distributed/distributed/nanny.py", line 846, in watch_stop_q
child_stop_q.close()
File "/Users/gabe/miniconda3/envs/dask-distributed/lib/python3.9/multiprocessing/queues.py", line 143, in close
self._reader.close()
File "/Users/gabe/miniconda3/envs/dask-distributed/lib/python3.9/multiprocessing/connection.py", line 182, in close
self._close()
File "/Users/gabe/miniconda3/envs/dask-distributed/lib/python3.9/multiprocessing/connection.py", line 366, in _close
_close(self._handle)
...
distributed.scheduler.KilledWorker: ("('random_sample-concatenate-1086077ac09ace0ac4330fce33825511', 2, 3)", <WorkerState 'tcp://127.0.0.1:65387', name: 2, status: closed, memory: 0, processing: 32>)
I'm not sure if this is a worker state regression. On scheduler side, the run_spec is a Serialized object in _task_to_msg
but the comm handler on worker side already has the above scrambled run_spec.
So either something is wrong in our serialization or with how we call handlers
Activity
fjetter commentedon Jun 24, 2022
The runspec at this point has the shape
{0: {'shape': (...), 'num-chunks': (...), 'array-location': [...], 'chunk-location': (...)}, None: {'shape': (...), 'num-chunks': (...), 'array-location': [...], 'chunk-location': (...), 'chunk-shape': (...), 'dtype': dtype('float64')}}fjetter commentedon Jun 24, 2022
I'm not sure if this is a worker state regression. On scheduler side, the run_spec is a
Serializedobject in_task_to_msgbut the comm handler on worker side already has the above scrambled run_spec.
So either something is wrong in our serialization or with how we call handlers
fjetter commentedon Jun 24, 2022
Git bisect shows that bd98e66 / #6410 is apparently the culprit
However, before this commit, I don't get a succesful run but rather the following exception instead
Partial revert of compute-task message format (#6626)