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

chore: Fix testCancelGetAttempt flaky test #3592

Merged
merged 3 commits into from
Feb 6, 2025

Conversation

lqiu96
Copy link
Contributor

@lqiu96 lqiu96 commented Jan 28, 2025

Fixes #2851

@product-auto-label product-auto-label bot added the size: m Pull request size is medium. label Jan 28, 2025
assertFutureCancel(future);
localExecutor.shutdownNow();
}
@Test
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Remove parameterized tests since it just chooses different retry settings. Only need to run this for a single set of retry settings.

@lqiu96 lqiu96 requested a review from zhumin8 February 3, 2025 22:19
@lqiu96 lqiu96 marked this pull request as ready for review February 3, 2025 22:19
Copy link

sonarqubecloud bot commented Feb 3, 2025

Copy link

sonarqubecloud bot commented Feb 3, 2025

Quality Gate Passed Quality Gate passed for 'java_showcase_integration_tests'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Copy link
Contributor

@zhumin8 zhumin8 left a comment

Choose a reason for hiding this comment

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

curious how you test this fix, given the flaky is happening not frequent I suppose? Or is your strategy to close any loopholes that may cause flaky failures?

@MethodSource("data")
void testCancelGetAttempt(boolean withCustomRetrySettings) throws Exception {
setUp(withCustomRetrySettings);
for (int executionsCount = 0; executionsCount < EXECUTIONS_COUNT; executionsCount++) {
Copy link
Contributor

Choose a reason for hiding this comment

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

can you explain a bit why we are removing this loop?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure why this even needs a loop to begin with. IIUC, the test should care that the future was cancelled after the first attempt. Running multiple invocations doesn't seem to be necessary.

Comment on lines +186 to +187
.setInitialRpcTimeoutDuration(java.time.Duration.ofMillis(50L))
.setMaxRpcTimeoutDuration(java.time.Duration.ofMillis(50L))
Copy link
Contributor

Choose a reason for hiding this comment

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

these are explicitly set instead of defaults to have quicker cancellations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, these were increased to give additional buffer time. IIRC, the original values were 8ms.

// this is a heavy test, which takes a lot of time, so only few executions.
for (int executionsCount = 0; executionsCount < 2; executionsCount++) {
// Use a test local executor for this test case due to the reasons listed below
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you mean above?

Suggested change
// Use a test local executor for this test case due to the reasons listed below
// Use a test local executor for this test case due to the reasons listed above

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, is to reference the comments below in L312-316. I kept this the same since I don't fully understand the impacts of changing it.

// future.cancel(true) may return false sometimes, which is ok. Also, the every cancellation
// of
// an already cancelled future should return false (this is what -1 means here)
assertEquals(2, checks - (failedCancelations - 1));
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this the failing point for #2851? Do you think it is redundant?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure what you're referring to. The test is to ensure that the future was cancelled during the retry attempt.

Future should be reported as done and that one attempt was made.

@lqiu96 lqiu96 merged commit c7d11d4 into main Feb 6, 2025
51 of 52 checks passed
@lqiu96 lqiu96 deleted the fix-testCancelGetAttempt-flaky branch February 6, 2025 02:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size: m Pull request size is medium.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ScheduledRetryingExecutorTest.testCancelGetAttempt is flaky
2 participants