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
[FLINK-20389][tests] Fix UnalignedCheckpointITCase to work with unassigned splits. #14250
Conversation
…igned splits. The test currently assumed that when induced failures happen, splits have been assigned to readers, which works fine for the planned snapshot-failure-recovery sequence. However, when unexpected failures happen, this assumption does not necessarily hold resulting in failures that may impede investigations. The test would still fail as the number of failures would be different from the expected numbers of failures, but investigation can focus on the unexpected failure then.
Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community Automated ChecksLast check on commit 12672b4 (Fri Nov 27 10:55:00 UTC 2020) Warnings:
Mention the bot in a comment to re-run the automated checks. Review Progress
Please see the Pull Request Review Guide for a full explanation of the review process. The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required Bot commandsThe @flinkbot bot supports the following commands:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
if (split != null) { | ||
LOG.info("notifyCheckpointComplete {} @ {} subtask (? attempt)", split.numCompletedCheckpoints, split.nextNumber % split.increment); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can split.increment
be 0 here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Increment = parallelism
, so it would be a bug at a different point. But good question.
What is the purpose of the change
The test currently assumed that when induced failures happen, splits have been assigned to readers, which works fine for the planned snapshot-failure-recovery sequence.
However, when unexpected failures happen, this assumption does not necessarily hold resulting in failures that may impede investigations.
The test would still fail as the number of failures would be different from the expected numbers of failures, but investigation can focus on the unexpected failure then.
Brief change log
Verifying this change
This commit is fixing a test.
Does this pull request potentially affect one of the following parts:
@Public(Evolving)
: (yes / no)Documentation