I'm going to investigate the failure Michael found, but due to existing commitments I'm unlikely to have time for it until tomorrow. Are folks ok with me holding this vote in limbo? Technically nobody has voted against yet (though I'm on the fence vs changing my vote pending my investigation) so if I close it without reversing my vote the release passes.
What's the feeling from the rest of the community on the best way to proceed? On Fri, Apr 26, 2024 at 10:18 AM Gus Heck <gus.h...@gmail.com> wrote: > Reproduced on my machine too, but it's a timeAllowed test that relies on > timeAllowed=0 which is arguably a degenerate setting, OTOH it did start > failing in march, and timeAllowed/Limits are something touched in this > release. > > > https://ge.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=solr-root&search.timeZoneId=America%2FNew_York&tests.container=org.apache.solr.analytics.legacy.facet.LegacyFieldFacetTest&tests.test=timeAllowedTest > > History on fucit however shows that it did have a spate of failures last > spring too: > > > http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.analytics.legacy.facet.LegacyFieldFacetTest.timeAllowedTest > > > On Fri, Apr 26, 2024 at 9:31 AM Michael Gibney <mich...@michaelgibney.net> > wrote: > >> I got a test failure that reproduces for me locally: >> >> gradlew :solr:modules:analytics:test --tests >> >> "org.apache.solr.analytics.legacy.facet.LegacyFieldFacetTest.timeAllowedTest" >> -Ptests.jvms=5 "-Ptests.jvmargs=-XX:TieredStopAtLevel=1 >> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 >> -XX:ReservedCodeCacheSize=120m" -Ptests.seed=F36DBDF5646C7DC2 >> -Ptests.badapples=false -Ptests.file.encoding=UTF-8 >> >> On Thu, Apr 25, 2024 at 11:46 PM David Smiley <dsmi...@apache.org> wrote: >> > >> > False alarm; it's a test bug that randomly re-orders docs at merge. >> > I'll file a PR in a bit. >> > >> > +1 vote for the release. >> > >> > On Thu, Apr 25, 2024 at 9:56 PM David Smiley <dsmi...@apache.org> >> wrote: >> > > >> > > I got a test failure that reproduces: >> > > ./gradlew :solr:core:test --tests >> > > "org.apache.solr.uninverting.TestUninvertingReader.testSortedSetFloat" >> > > -Ptests.seed=5827A2FA13E7BE3C >> > > Based on GE >> https://ge.apache.org/scans/tests?search.relativeStartTime=P90D&search.rootProjectNames=solr-root&search.timeZoneId=America%2FNew_York&tests.container=org.apache.solr.uninverting.TestUninvertingReader&tests.test=testSortedSetFloat >> > > and >> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.uninverting.TestUninvertingReader.testSortedSetInteger >> > > (notice looking at testSortedSetFloat vs testSortedSetInteger) >> > > these test methods on this suite have failed in the past since the >> > > start of this year. I ran a "git bisect" exploration and the test >> > > broke as of SOLR-17097: Upgrade Solr to use Lucene 9.9.2 (#2176). >> > > That shipped in Solr 9.5. I wish we had reproducer-detection / >> > > alerts. I'll file a JIRA issue for this bug. >> > > >> > > As to the seriousness... well this affects anyone using our Legacy >> > > numerics (vs Points) and who uninverts them (i.e. didn't enable >> > > docValues, which people _should_ be doing but it's easy to forget). >> > > >> > > The Smoketest passed for me when I ran it a second time. >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> > For additional commands, e-mail: dev-h...@solr.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org >> >> > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
