All 8000+ tests pass most of the time, but there are still a few that fail under the random conditions we test them in. This is a complete list of the known tests that fail and what is known about them. Note that these may not be all of the ways the tests can fail.
FAILED; unexpected exception
System.InvalidOperationException: cannot close: prepareCommit was already called with no corresponding call to commit
at Lucene.Net.Index.IndexWriter.CloseInternal(Boolean waitForMerges, Boolean doFlush) in F:\Projects\lucenenet\src\Lucene.Net\Index\IndexWriter.cs:line 1157
at Lucene.Net.Index.IndexWriter.Dispose(Boolean waitForMerges) in F:\Projects\lucenenet\src\Lucene.Net\Index\IndexWriter.cs:line 1096
at Lucene.Net.Index.IndexWriter.Dispose() in F:\Projects\lucenenet\src\Lucene.Net\Index\IndexWriter.cs:line 1053
at Lucene.Net.Index.TestIndexWriter.IndexerThreadInterrupt.Run() in F:\Projects\lucenenet\src\Lucene.Net.Tests\Index\TestIndexWriter.cs:line 1223
The error message doesn't occur when using lock (this} in IndexWriter.CommitInternal() to make PrepareCommitInternal() and FinishCommit() atomic, but the test still fails and the extra lock causes deadlocks in other tests. For some reason, the existing commitLock isn't completely atomic in some (unknown) case.
The test does not fail if both of the following lines are commented in TestIndexWriter.IndexerThreadInterrupt::Run() w.UpdateDocument(new Term("id", idField.GetStringValue()), doc); w.AddDocument(doc);
The test does not fail if RAMDirectory is used instead of MockDirectoryWrapper
It is quite possible that the problem is with MockDirectoryWrapper or one of its subcomponents, although the locking behavior of IndexWriter is also suspicious
Does not happen on Windows, but happens on both Linux and macOS
Related to current culture - fails with new CultureInfo("ar") specifically (and others)
Stack trace
System.FormatException : String '1/1/2002' was not recognized as a valid DateTime.
at System.DateTimeParse.Parse(ReadOnlySpan`1 s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
at Lucene.Net.QueryParsers.Flexible.Standard.TestQPHelper.AssertDateRangeQueryEquals(StandardQueryParser qp, String field, String startDate, String endDate, DateTime endDateInclusive, Resolution resolution) in D:\a\1\s\src\Lucene.Net.Tests.QueryParser\Flexible\Standard\TestQPHelper.cs:line 837
at Lucene.Net.QueryParsers.Flexible.Standard.TestQPHelper.TestDateRange() in D:\a\1\s\src\Lucene.Net.Tests.QueryParser\Flexible\Standard\TestQPHelper.cs:line 826
Happens on net451 on Windows, x86, in Release mode only (if Release, x86, or different target framework, does not fail)
Does not seem to fail using dotnet vstest, only fails in Visual Studio 2017/2019
Note we now have an azure-pipelines.yml configuration file in our repository that anyone can use to setup a build pipeline to see the tests run on Windows, macOS and Linux by setting up a free Azure DevOps account. If you create a public project to run the tests in, it will take roughly an hour to see the test results (a private project will take significantly longer on the free subscription because they only provide a single parallel job).
NOTES
If you want to work on one of these issues, please open a new JIRA ticket and make it "contained by" this one, so your efforts aren't duplicated by someone else. Assign the issue to yourself. If you can't work out the issue, make sure that you unassign yourself and comment on it below that it is still unresolved and up for grabs.
The code should be checked to make sure there were no translation problems from Java to C#. This may be easier than it sounds, as you can type phrases like "java HashMap equivalent c#" into Google to find the answers easily.
We can change the code to properly match the behavior of Java, but no cheating by changing the conditions of the test! Unless, of course, the test conditions were translated to C# wrong, which has been known to happen.
Random failures can often be made to happen more frequently by adding a RepeatAttribute to the top of the test. Try running 30 or 40 times and you will see the failure much more often.
If you find a solution to make the test pass, please open a PR on GitHub or alternatively post the solution here so we can try it ourselves.
If you get the same warm fuzzy feeling we do when we make a test green, feel free to fix another one.
Also, let us know if you find any failing test that is not on this list (aside from the "file in use by another process" issue that is known to happen with multiple tests on Linux and macOS - see LUCENENET-618 if you want to take a crack at that issue)
Up for grabs. Please contribute to Lucene.Net.
All 8000+ tests pass most of the time, but there are still a few that fail under the random conditions we test them in. This is a complete list of the known tests that fail and what is known about them. Note that these may not be all of the ways the tests can fail.
Lucene.Net.Search.TestSearchAfter::TestQueries()Lucene.Net.Util.TestVersionComparer::TestVersions()w.UpdateDocument(new Term("id", idField.GetStringValue()), doc);
w.AddDocument(doc);
Note we now have an azure-pipelines.yml configuration file in our repository that anyone can use to setup a build pipeline to see the tests run on Windows, macOS and Linux by setting up a free Azure DevOps account. If you create a public project to run the tests in, it will take roughly an hour to see the test results (a private project will take significantly longer on the free subscription because they only provide a single parallel job).
NOTES
Also, let us know if you find any failing test that is not on this list (aside from the "file in use by another process" issue that is known to happen with multiple tests on Linux and macOS - see LUCENENET-618 if you want to take a crack at that issue)
JIRA link - [LUCENENET-619] created by nightowl888