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

TL;DR: This is just a blatently bad test, and doesn't seem to indicate any 
sort of regression.  I don't think this failure should block the 
release.



Adding some debug logging to the test shows that the reason this seed can 
reproduce (on a fast machine) is because of the q param produced by this 
seed...

    q=int_id: [0 TO 21] AND long_ld: [0 TO 0]


..."0" is not a value that is ever indexed in the "long_ld" field in any 
document -- the indexing code uses it as a sentinal value to mean "skip 
this field for this doc" ...

      if (l != 0l) {
        fields.add("long_ld");
        fields.add("" + l);
        fields.add("long_ldm");
        fields.add("" + l);
      }

... so this query (with his seed) is garunteed to not to match any docs, 
which means the TimeLimitingBulkScorer.INTERVAL is never going to be 
exceeded by any code inside the IndexSearcher.

The analytics component itself seems to depend on ExitableDirectoryReader 
to enforce anything timeAllowed related -- but that hasn't been used by 
default since SOLR-16693 (and the abalytics component tests don't set the 
sysprop to force it to be used)


So...

1) timeAllowed=0 (a pathalogically non-sense input) sometimes doesn't 
trigger partialResults in SolrIndexSearcher when the query matchines no 
documents.

  ... shouldn't be a 9.6 release blocker IMO

2) AnalyticsHandler specific code hasn't respected timeAllowed (or any of the 
other new query limits) 
by default since Solr 9.3

  ... shouldn't be a 9.6 release blocker by any objectve standard






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

-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Reply via email to