-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
fix flaky test cases with a bit more robust waiting logic #8154
Conversation
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.
👍
// jobDetail and jobTrigger are not added atomically by the scheduler, | ||
// the jobDetail is added to an internal map firstly, and jobTrigger | ||
// is added to another internal map afterwards, so we check for the existence | ||
// of jobTrigger with some waits to be more defensive. |
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.
org.quartz.simpl.RAMJobStore:
public void storeJobAndTrigger(JobDetail newJob, OperableTrigger newTrigger) throws JobPersistenceException {
this.storeJob(newJob, false);
this.storeTrigger(newTrigger, false);
}
Codecov Report
@@ Coverage Diff @@
## master #8154 +/- ##
============================================
+ Coverage 71.39% 71.47% +0.08%
Complexity 4303 4303
============================================
Files 1624 1624
Lines 84198 84303 +105
Branches 12602 12635 +33
============================================
+ Hits 60116 60259 +143
+ Misses 19970 19919 -51
- Partials 4112 4125 +13
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
any thoughts on the compability check failure below?
|
2f8ece0
to
a6883ae
Compare
Description
fix flaky test cases with a bit more robust waiting logic, as the test cases wait for the ZK event to trigger the call backs.
Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)
backward-incompat
, and complete the section below on Release Notes)Does this PR fix a zero-downtime upgrade introduced earlier?
backward-incompat
, and complete the section below on Release Notes)Does this PR otherwise need attention when creating release notes? Things to consider:
release-notes
and complete the section on Release Notes)Release Notes
Documentation