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

Properly finish stage on noMorePartitions signal #19855

Merged
merged 2 commits into from
Nov 23, 2023

Conversation

losipiuk
Copy link
Member

Theoretically it is possible that all task partitions for a stage
complete before we get noMorePartitions signal from SplitAssigner.
In such case we should execute same finish routie as we do when last
task partition completes and noMorePartitions is already set.

This is cleanup, not a bugfix as currently no SplitAssigner
(even though it is not guaranteed by interface) would seal
all of the task partitions without returning noMorePartitions flag in
the same AssignmentResult object.

Release notes

(x) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

@cla-bot cla-bot bot added the cla-signed label Nov 21, 2023
@losipiuk losipiuk changed the title Properly finish stage when on noMorePartitions signal Properly finish stage on noMorePartitions signal Nov 21, 2023
Theoretically it is possible that all task partitions for a stage
complete before we get noMorePartitions signal from SplitAssigner.
In such case we should execute same finish routie as we do when last
task partition completes and noMorePartitions is already set.

This is cleanup, not a bugfix as currently no SplitAssigner
(even though it is not guaranteed by interface) would seal
all of the task partitions without returning noMorePartitions flag in
the same AssignmentResult object.
@losipiuk losipiuk force-pushed the lo/fix-no-more-partitions-fte branch from 066ae8e to ec3eff6 Compare November 21, 2023 22:47
@sopel39
Copy link
Member

sopel39 commented Nov 22, 2023

nit: is it worth having a test?

@losipiuk
Copy link
Member Author

nit: is it worth having a test?

It would be great. The problem is that so far we did not find any reasonable way of testing scheduer code at - other than running queries and seeing they work - but regarding corner cases like this one not really. Any suggestions are welcome

@losipiuk losipiuk merged commit 32dcd2b into trinodb:master Nov 23, 2023
88 checks passed
@github-actions github-actions bot added this to the 434 milestone Nov 23, 2023
@sopel39
Copy link
Member

sopel39 commented Nov 23, 2023

The problem is that so far we did not find any reasonable way of testing scheduer code at

Could we have some dummy "scenarios" that we use for testing scheduler and check if it behaves in expected way?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants