Hi Phil,
Solr has a number of tests that are flaky and fail seemingly at
random. Some of this is true flakiness: bugs that only occur with
certain timing behavior. Some of it is driven by the Solr Test
Framework's heavy use of randomization in running test cases. ("ant
test" assigns seeds for test runs which are used to randomize aspects
of test execution: locale and timezone settings, the number of Solr
nodes or shards or documents used in certain tests, the client
settings used to talk to Solr, etc.) Unfortunately, failures do
happen.
Ideally any failure would be investigated by developers as soon as it
occurs, but the extent of the randomization in play and the trickiness
of reproducing failures that may be timing-dependent means this often
isn't feasible in practice.
So where failures are reproducible, it's generally good practice to
let the community know what you found by reporting the failure on
"d...@solr.apache.org", or by recording the failure in a JIRA ticket
along with details about your environment and the "seed" used by the
test. Or even better - by investigating yourself.
But where a failure isn't easily reproducible and you haven't made any
changes to related code, it's normal to let them go.
Best,
Jason
On Wed, Apr 14, 2021 at 3:20 PM Phill Campbell
<sirgilli...@yahoo.com.invalid> wrote:
>
> I have downloaded Solr 8.2.2 source code. I am using a Mac running Catalina.
> Using ANT with “clean compile test” everything is good.
>
> From Intellij I tried running tests and several failed.
> Here is an example:
>
> package org.apache.solr.analysis;
> ...
> public class TestWordDelimiterFilterFactory
> ...
>
> @Test
> public void testIgnoreCaseChange()
>
> ...
>
> assertQ("case change",
> req("subword:(good jon)")
> ,"//result[@numFound=1]"
> );
>
>
> Should I worry about that?
> What should I do?
>
> Thank you.
