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

Disable TestValidateIncompatibleCentralizedDatasourceSchemaConfig #16627

Merged
merged 7 commits into from
Jun 19, 2024

Conversation

findingrish
Copy link
Contributor

It seems that the system properties being set in this test is causing org.apache.druid.cli.MainTest to fail, ex: https://github.com/apache/druid/actions/runs/9561791589/job/26357426307?pr=16620.

Disabling this test for now, will find another way to set configs.

Copy link
Contributor

@abhishekrb19 abhishekrb19 left a comment

Choose a reason for hiding this comment

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

@findingrish do you have an idea why this test started causing CI failures only recently? I see that this test was introduced in #15817, which was merged more than a month ago.

@@ -51,6 +52,9 @@ public TestValidateIncompatibleCentralizedDatasourceSchemaConfig(ServerRunnable
this.runnable = runnable;
}

// It seems that setting the system properties is causing MainTest to fail.
// Ignoring this test until there is a better way to set the properties.
@Ignore
@Test(expected = RuntimeException.class)
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this line is the problem. Looking at this test, an exception is expected to be thrown when the runnable gets the system properties in L68-69.

After an exception is thrown, it doesn't clear the properties set from L71-73 causing the incompatible system properties to be "leaked".

A couple of points regarding fixing this test:

  1. Instead of setting system-wide properties that can affect other tests broadly, you can bind the supplied properties to the Guice injector instance. For example, please see SqlModuleTest.java. This way, the properties would only be scoped to this test injector.
  2. One of the problems with expected exceptions @Test(expected = Foo.class) is that it doesn't tell us which line of code is expected to throw the exception. We should use Assert.assertThrows() with a narrow code block around lines 68-69.

Copy link
Contributor

@abhishekrb19 abhishekrb19 left a comment

Choose a reason for hiding this comment

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

Okay, I see that the test order plays a role here and the order is non-deterministic AFAIK. So maybe it's just a coincidence that this started happening more recently? 🤔

Regardless, ignoring the test looks fine to unblock the CI pipeline. I restarted the two failed cds* ITs, but they have been failing on other PRs too, so we can ignore them for now.

@abhishekrb19 abhishekrb19 merged commit 169a8db into apache:master Jun 19, 2024
86 of 87 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants