Address resolution not consistent

[fjetter]

Dask typically can work with fully resolved host addresses (127.0.0.1:1234 ) or hostnames (localhost:1234) interchangeably by resolving the hostname where necessary.

We have various toggle over the code base controlling this behaviour

• Scheduler.coerce_address
• Scheduler.heartbeat_worker
• Scheduler.add_worker
• distributed.worker.get_client

They are all accessing distributed.com.addressing.resolve_address which then dispatches the resolve to the used network backend based on the URL scheme.

We're not very consistent in this behaviour and I believe that if we want to resolve addresses, we should resolve all addresses as soon as the user passes them in.

Particularly, where we're not resolving addresses are

• Client.__init__ and here
• Nanny.__init__
• Worker.__init__

This can cause confusing and wrong behaviour whenever we're comparing addresses, e.g.

• distributed/distributed/actor.py

  Lines 173 to 177 in e1e4385

  	if (
  	self._worker
  	and self._worker.address == self._address
  	and getattr(thread_state, "actor", False)
  	):

• Client._gather
• Client._scatter
• serialized Queues
• serialized Variables
• Worker._get_client (This causes the failure in Ensure default client mechanism is threadsafe #5901 (comment))
• ...

Side note: There is an ambiguous, not documented Scheduler.coerce_hostname which is not connected to address resolution but rather checks the internal list of aliases

• I would suggest to remove the kwargs in most of the functions and replace it with a config toggle, if we want to allow toggling.
• We should ensure that this behaviour is consistent, e.g. all addresses are always resolved or never