@@ -3118,8 +3118,8 @@ async def test_compute_partially_forgotten(c, s, *workers, validate, swap_keys):
31183118 s .validate = False
31193119 # (CPython impl detail)
31203120 # While it is not possible to know what the iteration order of a set will
3121- # be, it is determinisitic and only depends on the hash of the inserted
3122- # elements. Therefore, converting the set to a list will alway yield the
3121+ # be, it is deterministic and only depends on the hash of the inserted
3122+ # elements. Therefore, converting the set to a list will always yield the
31233123 # same order. We're initializing the keys in this very specific order to
31243124 # ensure that the scheduler internally arranges the keys in this way
31253125
@@ -4733,7 +4733,7 @@ async def test_retire_workers(c, s, a, b):
47334733 info = await c .retire_workers (workers = [a .address ], close_workers = True )
47344734
47354735 # Deployment tooling is sometimes relying on this information to be returned
4736- # This represents WorkerState.idenity () right now but may be slimmed down in
4736+ # This represents WorkerState.identity () right now but may be slimmed down in
47374737 # the future
47384738 assert info
47394739 assert info [a .address ]
@@ -8301,7 +8301,7 @@ def test_worker_clients_do_not_claim_ownership_of_serialize_futures(
83018301 # different process such that we cannot rely on msg ordering
83028302 #
83038303 # 1. The alive futures have to be serialized as part of the submit payload
8304- # 2. The future arive at the worker but the worker client doesn't claim
8304+ # 2. The future arrive at the worker but the worker client doesn't claim
83058305 # ownership
83068306 # 3. We're deleting them and the cancellation goes through to the scheduler
83078307 # such that it can release the futures
0 commit comments