Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harden preamble of Worker.execute against race conditions #6878

Merged
merged 1 commit into from
Aug 12, 2022

Conversation

crusaderky
Copy link
Collaborator

# This is just for internal coherence of the WorkerState; the reschedule
# message should not ever reach the Scheduler.
# It is still OK if it does though.
return RescheduleEvent(key=key, stimulus_id=f"worker-closing-{time()}")
Copy link
Collaborator Author

@crusaderky crusaderky Aug 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two new tests remain green if you revert the first line of this block:

if self.status in {Status.closing, Status.closed, Status.closing_gracefully}:
    return RescheduleEvent(key=key, stimulus_id=f"worker-closing-{time()}")

In this case, the reschedule event actually reaches the scheduler.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned that this causes the scheduler to reschedule a task twice. First, because the worker left, and second, because the reschedule event arrives.
Why is the previous version of returning None not sufficient?

Edit:

if worker and ts.processing_on.address != worker:
return
scheduler verifies the reschedule event +1

"Trying to execute task %s which is not in executing state anymore",
ts,
)
return AlreadyCancelledEvent(key=ts.key, stimulus_id=stimulus_id)
Copy link
Collaborator Author

@crusaderky crusaderky Aug 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two new tests remain green if, instead of removing this block completely, you just replace the exit event with

return RescheduleEvent(key=key, stimulus_id=f"already-cancelled-{time()}")

They also remain green if you copy-paste the same block after the call to _maybe_deserialize_task.
In both cases, the reschedule event reaches the scheduler and behaves as expected.

@crusaderky crusaderky added the deadlock The cluster appears to not make any progress label Aug 11, 2022
ts,
)
return AlreadyCancelledEvent(key=ts.key, stimulus_id=stimulus_id)
if self.status not in WORKER_ANY_RUNNING:
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

align execute and gather_dep

@crusaderky crusaderky self-assigned this Aug 11, 2022
@github-actions
Copy link
Contributor

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

       15 files  ±    0         15 suites  ±0   6h 24m 56s ⏱️ - 8m 24s
  3 000 tests +    8    2 908 ✔️ +    5       88 💤  -   1  4 +4 
22 246 runs   - 532  21 192 ✔️  - 458  1 050 💤  - 78  4 +4 

For more details on these failures, see this check.

Results for commit 38bf365. ± Comparison against base commit 99a2db1.

Copy link
Member

@fjetter fjetter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Thanks @crusaderky !

# This is just for internal coherence of the WorkerState; the reschedule
# message should not ever reach the Scheduler.
# It is still OK if it does though.
return RescheduleEvent(key=key, stimulus_id=f"worker-closing-{time()}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm concerned that this causes the scheduler to reschedule a task twice. First, because the worker left, and second, because the reschedule event arrives.
Why is the previous version of returning None not sufficient?

Edit:

if worker and ts.processing_on.address != worker:
return
scheduler verifies the reschedule event +1

@fjetter fjetter merged commit 832b280 into dask:main Aug 12, 2022
@crusaderky crusaderky deleted the execute_preamble branch August 12, 2022 14:01
gjoseph92 pushed a commit to gjoseph92/distributed that referenced this pull request Oct 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deadlock The cluster appears to not make any progress
Projects
None yet
2 participants