Known Failing Tests on Lucene.Net

[clambertus]

All 7500+ 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.Index.TestTermVectorsWriter::TestTermVectorCorruption() and Lucene.Net.Index.TestIndexWriterReader::TestDuringAddIndexes()
  • Fails with a message like System.IO.IOException : The process cannot access the file '/tmp/LuceneTemp/index-NIOFSDirectory-fkqg2vah/write.lock' because it is being used by another process.
  • Happens on macOS and Linux, but not on Windows
• Lucene.Net.Search.TestSearchAfter::TestQueries()
  • Related to current culture
  • Happens on netcoreapp2.1 on macOS
  • Happens on netcoreapp1.0 on Linux
• Lucene.Net.Util.TestVersionComparer::TestVersions()
  • Related to current culture
  • Happens on netcoreapp2.1 on macOS
• Lucene.Net.Index.TestIndexWriter::TestTwoThreadsInterruptDeadlock()
  • Happens on every target framework/OS
  • Fixed in Fixes Lucene.Net.Index.TestIndexWriter::TestThreadInterruptDeadlock() and Lucene.Net.Index.TestIndexWriter::TestTwoThreadsInterruptDeadlock() #525
• Lucene.Net.Index.TestIndexWriter::TestThreadInterruptDeadlock()
  • Happens on every target framework/OS
  • Fixed in Fixes Lucene.Net.Index.TestIndexWriter::TestThreadInterruptDeadlock() and Lucene.Net.Index.TestIndexWriter::TestTwoThreadsInterruptDeadlock() #525
  • The error message doesn't occur when using lock (this) in IndexWriter.CommitInternal() to make PrepareCommitInternal()
  • 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
  • Fails with message:

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

• Lucene.Net.Classification.KNearestNeighborClassifierTest::TestPerformance()
  • Happens on netcoreapp2.1 on Windows
  • Happens on net451 on Windows
• Lucene.Net.Analysis.NGram.EdgeNGramTokenizerTest::TestFullUTF8Range()
• Lucene.Net.Analysis.NGram.NGramTokenizerTest::TestFullUTF8Range()
  • Happens on net451 on Windows
  • Happens on netcoreapp2.1 on macOS
• Lucene.Net.Search.VectorHighlight.SimpleFragmentsBuilderTest::
  TestRandomDiscreteMultiValueHighlighting()
  • Happens on Windows
  • Not related to current culture
  • Definitely a problem with the highlighter, not the test or test framework
  • As of 2020-07-23, this test no longer fails even after running continuously with different seeds for 8 minutes. I suspect that the J2N structural equality comparer fix NightOwl888/J2N@33382d9 inadvertently fixed this issue.
• Lucene.Net.QueryParsers.Flexible.Standard.TestQPHelper::TestDateRange()
  • Does not happen on Windows, but happens on both Linux and macOS
  • Related to current culture - fails with new CultureInfo("ar") specifically (and others)
  • As of 2020-08-11, this test hasn't failed for several hundred test runs on Azure DevOps.
  • 2021-11-19 - The test started failing again after fixing the random seed functionality in the test framework. It was fixed in BUG: Lucene.Net.Tests.QueryParser.Flexible.Standard.TestQPHelper: Use ParseExact to specify the date format #543.
  • 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

• Lucene.Net.Expressions.TestExpressionSorts::TestQueries()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Sandbox.TestSlowFuzzyQuery::TestTieBreaker()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Sandbox.TestSlowFuzzyQuery::TestTokenLengthOpt()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Search.TestBooleanQuery::TestBS2DisjunctionNextVsAdvance()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Search.TestFuzzyQuery::TestTieBreaker()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Search.TestSearchAfter::TestQueries()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Search.TestTopDocsMerge::TestSort_1()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Search.TestTopDocsMerge::TestSort_2()

  • Happens on .NET Framework on Windows, x86, in Release mode only (if not Release, x86, or different target framework, does not fail)
  • Does not fail when optimizations are disabled in Lucene.Net.dll
  • Fixed in Fix for .NET Framework x86 Support #529

• Lucene.Net.Index.TestTaskMergeScheduler::TestSubclassTaskMergeScheduler()

  • 2020-02-18 - Deprecated TaskMergeScheduler and deleted its tests, so this is no longer applicable
  • Happens rarely
  • Stack Trace:

System.ObjectDisposedException : Cannot access a disposed object.
at System.Threading.ReaderWriterLockSlim.TryEnterReadLockCore(TimeoutTracker timeout)
at System.Threading.ReaderWriterLockSlim.EnterReadLock()
at Lucene.Net.Support.Threading.ReaderWriterLockSlimExtensions.ReadLockToken..ctor(ReaderWriterLockSlim sync) in D:\a\1\s\src\Lucene.Net\Support\Threading\ReaderWriterLockSlimExtensions.cs:line 40
at Lucene.Net.Support.Threading.ReaderWriterLockSlimExtensions.Read(ReaderWriterLockSlim obj) in D:\a\1\s\src\Lucene.Net\Support\Threading\ReaderWriterLockSlimExtensions.cs:line 74
at Lucene.Net.Index.TaskMergeScheduler.MergeThread.get_IsAlive() in D:\a\1\s\src\Lucene.Net\Support\Index\TaskMergeScheduler.cs:line 535
at Lucene.Net.Index.TaskMergeScheduler.Sync() in D:\a\1\s\src\Lucene.Net\Support\Index\TaskMergeScheduler.cs:line 191
at Lucene.Net.Index.TestTaskMergeScheduler.TestSubclassTaskMergeScheduler() in D:\a\1\s\src\Lucene.Net.Tests\Support\Index\TestTaskMergeScheduler.cs:line 106

• Lucene.Net.Analysis.Th.TestThaiAnalyzer::TestRandomStrings()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur
  • Does not occur when these lines are commented - this is definitely a concurrency problem. See Fix/random seed simple #313 (comment).
  • See Fix/random seed simple #313
• Lucene.Net.Analysis.Th.TestThaiAnalyzer::TestRandomHugeStrings()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur
  • Does not occur when these lines are commented - this is definitely a concurrency problem. See Fix/random seed simple #313 (comment).
  • See Fix/random seed simple #313
• Lucene.Net.Analysis.Icu.TestICUFoldingFilter::TestRandomStrings()
  • This turned out to be an issue with culture sensitivity that was introduced in 4.8.0-beta00008. See Fix for analysis culture sensitivity and surrogate pair support #321.
• Lucene.Net.Analysis.Icu.TestICUTokenizerCJK::TestRandomStrings()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur
  • Does not occur when these lines are commented - this is definitely a concurrency problem. See Fix/random seed simple #313 (comment).
  • The temporary patch in Temporary thread safety fix for ICUTokenizer/Locking patches for AttributeSource #328 makes this test pass and is proof that this is a concurrency problem with BreakIterator, and ffc8f2a can be reverted once it is fixed.
• Lucene.Net.Analysis.Icu.TestICUTokenizerCJK::TestRandomHugeStrings()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur
  • Does not occur when these lines are commented - this is definitely a concurrency problem. See Fix/random seed simple #313 (comment).
  • The temporary patch in Temporary thread safety fix for ICUTokenizer/Locking patches for AttributeSource #328 makes this test pass and is proof that this is a concurrency problem with BreakIterator, and ffc8f2a can be reverted once it is fixed.
• Lucene.Net.Analysis.Icu.TestICUTokenizer::TestRandomStrings()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur
  • Does not occur when these lines are commented - this is definitely a concurrency problem. See Fix/random seed simple #313 (comment).
  • The temporary patch in Temporary thread safety fix for ICUTokenizer/Locking patches for AttributeSource #328 makes this test pass and is proof that this is a concurrency problem with BreakIterator, and ffc8f2a can be reverted once it is fixed.
• Lucene.Net.Analysis.Icu.TestICUTokenizer::TestRandomHugeStrings()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur
  • Does not occur when these lines are commented - this is definitely a concurrency problem. See Fix/random seed simple #313 (comment).
  • The temporary patch in Temporary thread safety fix for ICUTokenizer/Locking patches for AttributeSource #328 makes this test pass and is proof that this is a concurrency problem with BreakIterator, and ffc8f2a can be reverted once it is fixed.
• Lucene.Net.Index.TestIndexWriterWithThreads::TestRollbackAndCommitWithThreads()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur
  • Began appearing when Create replacement for Debug.Assert() that can be turned on/off in Release build #326 was put into place
  • Patched in DocumentsWriterThreadPool upgrade to 4.8.1 (fixes TestRollbackAndCommitWithThreads() test) #335
• Lucene.Net.Analysis.Icu.TestICUFoldingFilterFactory::Test()
  • Only fails on Ubuntu 18.04 when running on GitHub Actions hosted agent
  • Does not fail using Ubuntu 18.04 on Azure DevOps
  • Stack Trace:

Lucene.Net.Diagnostics.AssertionException : End() called before IncrementToken() returned false!  1) Expected: resume, Actual: r�sum�
term 0, output[i] = resume, termAtt = r�sum�
at Lucene.Net.Analysis.MockTokenizer.End() in /home/runner/work/lucenenet/lucenenet/src/Lucene.Net.TestFramework/Analysis/MockTokenizer.cs:line 336

at Lucene.Net.Analysis.BaseTokenStreamTestCase.AssertTokenStreamContents(TokenStream ts, String[] output, Int32[] startOffsets, Int32[] endOffsets, String[] types, Int32[] posIncrements, Int32[] posLengths, Nullable1 finalOffset, Nullable1 finalPosInc, Boolean[] keywordAtts, Boolean offsetsAreCorrect, Byte[][] payloads) in /home/runner/work/lucenenet/lucenenet/src/Lucene.Net.TestFramework/Analysis/BaseTokenStreamTestCase.cs:line 415

at Lucene.Net.Analysis.BaseTokenStreamTestCase.AssertTokenStreamContents(TokenStream ts, String[] output, Int32[] startOffsets, Int32[] endOffsets, String[] types, Int32[] posIncrements, Int32[] posLengths, Nullable1 finalOffset, Boolean[] keywordAtts, Boolean offsetsAreCorrect) in /home/runner/work/lucenenet/lucenenet/src/Lucene.Net.TestFramework/Analysis/BaseTokenStreamTestCase.cs:line 428 at Lucene.Net.Analysis.BaseTokenStreamTestCase.AssertTokenStreamContents(TokenStream ts, String[] output, Int32[] startOffsets, Int32[] endOffsets, String[] types, Int32[] posIncrements, Int32[] posLengths, Nullable1 finalOffset, Boolean offsetsAreCorrect) in /home/runner/work/lucenenet/lucenenet/src/Lucene.Net.TestFramework/Analysis/BaseTokenStreamTestCase.cs:line 433

at Lucene.Net.Analysis.BaseTokenStreamTestCase.AssertTokenStreamContents(TokenStream ts, String[] output, Int32[] startOffsets, Int32[] endOffsets, String[] types, Int32[] posIncrements, Int32[] posLengths, Nullable`1 finalOffset) in /home/runner/work/lucenenet/lucenenet/src/Lucene.Net.TestFramework/Analysis/BaseTokenStreamTestCase.cs:line 438

at Lucene.Net.Analysis.BaseTokenStreamTestCase.AssertTokenStreamContents(TokenStream ts, String[] output) in /home/runner/work/lucenenet/lucenenet/src/Lucene.Net.TestFramework/Analysis/BaseTokenStreamTestCase.cs:line 453

at Lucene.Net.Analysis.Icu.TestICUFoldingFilterFactory.Test() in /home/runner/work/lucenenet/lucenenet/src/Lucene.Net.Tests.Analysis.ICU/Analysis/Icu/TestICUFoldingFilterFactory.cs:line 39

• Lucene.Net.Analysis.Core.TestRandomChains::TestRandomChains_() and Lucene.Net.Analysis.Core.TestRandomChains::TestRandomChainsWithLargeStrings()
  • Happens so rarely that it requires [FindFirstFailingSeed] or [Repeat(100)] attribute to force it to occur (this no longer works after fixing the random seed functionality in the test framwork, we need to wait for it to happen in Azure DevOps)
  • Began appearing when Create replacement for Debug.Assert() that can be turned on/off in Release build #326 was put into place
  • 2021-11-19 - The cause is now known - see TokenStream.IncrementToken() is called after Dispose() is called #271 (comment).
  • Upon multiple runs, the only common failure point seems to be HunspellStemFilter
  • Stack Trace:

Test Name:	TestRandomChainsWithLargeStrings
Test Outcome:	Failed
Result Message:	
Thread threw exception: Lucene.Net.Diagnostics.AssertionException: accCount=1 vs existing accept=False states=[0:1]
   at Lucene.Net.Util.Automaton.BasicOperations.Determinize(Automaton a) in F:\Projects\lucenenet\src\Lucene.Net\Util\Automaton\BasicOperations.cs:line 874
   at Lucene.Net.Util.Automaton.MinimizationOperations.MinimizeHopcroft(Automaton a) in F:\Projects\lucenenet\src\Lucene.Net\Util\Automaton\MinimizationOperations.cs:line 67
   at Lucene.Net.Util.Automaton.RegExp.ToAutomaton(IDictionary`2 automata, IAutomatonProvider automaton_provider) in F:\Projects\lucenenet\src\Lucene.Net\Util\Automaton\RegExp.cs:line 616
   at Lucene.Net.Analysis.Hunspell.Dictionary.ParseAffix(SortedDictionary`2 affixes, String header, TextReader reader, String conditionPattern, IDictionary`2 seenPatterns, IDictionary`2 seenStrips) in F:\Projects\lucenenet\src\Lucene.Net.Analysis.Common\Analysis\Hunspell\Dictionary.cs:line 498
   at Lucene.Net.Analysis.Hunspell.Dictionary.ReadAffixFile(Stream affixStream, Encoding decoder) in F:\Projects\lucenenet\src\Lucene.Net.Analysis.Common\Analysis\Hunspell\Dictionary.cs:line 301
   at Lucene.Net.Analysis.Hunspell.Dictionary..ctor(Stream affix, IList`1 dictionaries, Boolean ignoreCase) in F:\Projects\lucenenet\src\Lucene.Net.Analysis.Common\Analysis\Hunspell\Dictionary.cs:line 162
   at Lucene.Net.Analysis.Hunspell.Dictionary..ctor(Stream affix, Stream dictionary) in F:\Projects\lucenenet\src\Lucene.Net.Analysis.Common\Analysis\Hunspell\Dictionary.cs:line 125
   at Lucene.Net.Analysis.Core.TestRandomChains.DictionaryArgProducer.Create(Random random) in F:\Projects\lucenenet\src\Lucene.Net.Tests.Analysis.Common\Analysis\Core\TestRandomChains.cs:line 511
   at Lucene.Net.Analysis.Core.TestRandomChains.NewRandomArg[T](Random random, Type paramType) in F:\Projects\lucenenet\src\Lucene.Net.Tests.Analysis.Common\Analysis\Core\TestRandomChains.cs:line 747
   at Lucene.Net.Analysis.Core.TestRandomChains.NewFilterArgs(Random random, TokenStream stream, Type[] paramTypes) in F:\Projects\lucenenet\src\Lucene.Net.Tests.Analysis.Common\Analysis\Core\TestRandomChains.cs:line 810
   at Lucene.Net.Analysis.Core.TestRandomChains.MockRandomAnalyzer.NewFilterChain(Random random, Tokenizer tokenizer, Boolean offsetsAreCorrect) in F:\Projects\lucenenet\src\Lucene.Net.Tests.Analysis.Common\Analysis\Core\TestRandomChains.cs:line 1023
   at Lucene.Net.Analysis.Core.TestRandomChains.MockRandomAnalyzer.CreateComponents(String fieldName, TextReader reader) in F:\Projects\lucenenet\src\Lucene.Net.Tests.Analysis.Common\Analysis\Core\TestRandomChains.cs:line 849
   at Lucene.Net.Analysis.Analyzer.GetTokenStream(String fieldName, TextReader reader) in F:\Projects\lucenenet\src\Lucene.Net\Analysis\Analyzer.cs:line 265
   at Lucene.Net.Analysis.BaseTokenStreamTestCase.CheckAnalysisConsistency(Random random, Analyzer a, Boolean useCharFilter, String text, Boolean offsetsAreCorrect, Field field) in F:\Projects\lucenenet\src\Lucene.Net.TestFramework\Analysis\BaseTokenStreamTestCase.cs:line 1044
   at Lucene.Net.Analysis.BaseTokenStreamTestCase.CheckRandomData(Random random, Analyzer a, Int32 iterations, Int32 maxWordLength, Boolean useCharFilter, Boolean simple, Boolean offsetsAreCorrect, RandomIndexWriter iw) in F:\Projects\lucenenet\src\Lucene.Net.TestFramework\Analysis\BaseTokenStreamTestCase.cs:line 929
   at Lucene.Net.Analysis.BaseTokenStreamTestCase.AnalysisThread.Run() in F:\Projects\lucenenet\src\Lucene.Net.TestFramework\Analysis\BaseTokenStreamTestCase.cs:line 735
Result StandardOutput:	
Exception from random analyzer: 
charfilters=
  HTMLStripCharFilter([System.IO.StringReader])
  PatternReplaceCharFilter([a, , Lucene.Net.Analysis.CharFilters.HTMLStripCharFilter])
tokenizer=
  ReversePathHierarchyTokenizer([Lucene.Net.Analysis.Core.TestRandomChains+CheckThatYouDidntReadAnythingReaderWrapper, 蒫, 醙, 24])
filters=
  CJKBigramFilter([ValidatingTokenFilter@368e0a2 term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,type=word,positionLength=1, 83])
  IndonesianStemFilter([ValidatingTokenFilter@25a042e term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,type=word,positionLength=1,keyword=False, false])
  HunspellStemFilter([ValidatingTokenFilter@20aee5b term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,type=word,positionLength=1,keyword=False, Lucene.Net.Analysis.Hunspell.Dictionary, true, false])
  LatvianStemFilter([ValidatingTokenFilter@6f125a term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,type=word,positionLength=1,keyword=False])
offsetsAreCorrect=False
Result StandardError:	TEST FAIL: useCharFilter=True text='smfmwktkf \\'\\'

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).

Repeatability

The tests that fail are now marked with the AwaitsFixAttribute. The default behavior of the test framework is to ignore the tests that are marked with this attribute. Any of the following changes can be made to make the AwaitsFixAttribute tests run so they can be debugged.

1. Comment the AwaitsFixAttribute on the test in question.
2. Add a file named lucene.testsettings.json in the directory of the test project or a parent directory of the test project with the content:

 {
  "tests": {
    "awaitsfix": "true"
  }
}

To specify a specific target framework to run the tests on, edit the TestTargetFramework.props file. Note that the last property with a given name wins, so to test on .NET Core 3.1 instead of .NET 5, change the file as follows:

Before

    <!--<TargetFramework>net48</TargetFramework>-->
    <!--<TargetFramework>netcoreapp2.1</TargetFramework>-->
    <!--<TargetFramework>netcoreapp3.1</TargetFramework>-->
    <TargetFramework>net5.0</TargetFramework>

After

    <!--<TargetFramework>net48</TargetFramework>-->
    <!--<TargetFramework>netcoreapp2.1</TargetFramework>-->
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <!--<TargetFramework>net5.0</TargetFramework>-->

NOTES

• If you want to work on one of these issues, please open a new GitHub issue and make it refer to 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.
• Sometimes problems can be spotted just by comparing the Lucene 4.8.0 code against Lucene.Net 4.8.0 code.
• 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.

JIRA link - [LUCENENET-619] created by nightowl888