Remove ORM 6.2 upgrade job since 7.0 targets 6.3+

[marko-bekhta]

I'll look into other failed branches, so opening this as a draft for now

[hibernate-github-bot]

Thanks for your pull request!

This pull request does not follow the contribution rules. Could you have a look?

❌ All commit messages should start with a JIRA issue key matching pattern HSEARCH-\d+
    ↳ Offending commits: [3e61ab5, 016a53c]

› This message was automatically generated.

[marko-bekhta]

The Elasticsearch build failed with the usual error "not supporting extreme scaled numeric values" as that bug is not fixed yet.
As for the Lucene build... the error was in the area we've changed to not rely on NO_MORE_ORDS constant (or whatever the name for it was ...) but I cannot reproduce this locally 🤷🏻‍♂️ 😔

[yrodiere]

As for the Lucene build... the error was in the area we've changed to not rely on NO_MORE_ORDS constant (or whatever the name for it was ...) but I cannot reproduce this locally 🤷🏻‍♂️ 😔

We're talking about this one, I assume:

[ERROR] Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.560 s <<< FAILURE! -- in org.hibernate.search.integrationtest.showcase.library.LibraryShowcaseSearchIT
[ERROR] org.hibernate.search.integrationtest.showcase.library.LibraryShowcaseSearchIT.searchFaceted -- Time elapsed: 0.031 s <<< ERROR!
java.lang.IndexOutOfBoundsException
	at java.base/java.nio.Buffer.checkIndex(Buffer.java:743)
	at java.base/java.nio.DirectByteBuffer.get(DirectByteBuffer.java:339)
	at org.apache.lucene.store.ByteBufferGuard.getByte(ByteBufferGuard.java:115)
	at org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl.readByte(ByteBufferIndexInput.java:564)
	at org.apache.lucene.util.packed.DirectReader$DirectPackedReader2.get(DirectReader.java:222)
	at org.apache.lucene.codecs.lucene90.Lucene90DocValuesProducer$25.nextOrd(Lucene90DocValuesProducer.java:1468)
	at org.hibernate.search.backend.lucene.lowlevel.docvalues.impl.TextMultiValues$DocValuesTextMultiValues.nextOrd(TextMultiValues.java:122)
	at org.hibernate.search.backend.lucene.lowlevel.facet.impl.TextMultiValueFacetCounts.countOneSegment(TextMultiValueFacetCounts.java:184)
	at org.hibernate.search.backend.lucene.lowlevel.facet.impl.TextMultiValueFacetCounts.count(TextMultiValueFacetCounts.java:246)
	at org.hibernate.search.backend.lucene.lowlevel.facet.impl.TextMultiValueFacetCounts.<init>(TextMultiValueFacetCounts.java:59)
	at org.hibernate.search.backend.lucene.types.aggregation.impl.LuceneTextTermsAggregation.getTopChildren(LuceneTextTermsAggregation.java:51)
	at org.hibernate.search.backend.lucene.types.aggregation.impl.AbstractLuceneFacetsBasedTermsAggregation.getTopBuckets(AbstractLuceneFacetsBasedTermsAggregation.java:125)
	at org.hibernate.search.backend.lucene.types.aggregation.impl.AbstractLuceneFacetsBasedTermsAggregation.extract(AbstractLuceneFacetsBasedTermsAggregation.java:65)
	at org.hibernate.search.backend.lucene.types.aggregation.impl.AbstractLuceneFacetsBasedTermsAggregation.extract(AbstractLuceneFacetsBasedTermsAggregation.java:39)
	at org.hibernate.search.backend.lucene.search.query.impl.LuceneExtractableSearchResult.extractAggregations(LuceneExtractableSearchResult.java:130)
	at org.hibernate.search.backend.lucene.search.query.impl.LuceneExtractableSearchResult.extract(LuceneExtractableSearchResult.java:77)
	at org.hibernate.search.backend.lucene.search.query.impl.LuceneExtractableSearchResult.extract(LuceneExtractableSearchResult.java:58)
	at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearcherImpl.search(LuceneSearcherImpl.java:75)
	at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearcherImpl.search(LuceneSearcherImpl.java:32)
	at org.hibernate.search.backend.lucene.work.impl.SearchWork.execute(SearchWork.java:41)

This could be a regression in Lucene 10.0.0-SNAPSHOT, especially since there's been a change in this class recently: apache/lucene@d633c9b . Ironically, the problem that patch fixed looks a lot like the stacktrace above.

This could be also a bug in our code that happens only with a certain index fragment topology (documents spear among fragments a certain way), which could make the bug timing-sensitive. But I'd save that theory for last, because that will be very difficult to debug.

Other theory: we don't go through docvalues correctly. I see references to DocIdSetIterator.NO_MORE_DOCS throughout the code, in particularly there:

hibernate-search/backend/lucene/src/main/java/org/hibernate/search/backend/lucene/lowlevel/facet/impl/TextMultiValueFacetCounts.java

Line 179 in 5fccd1a

for ( int doc = docs.nextDoc(); doc != DocIdSetIterator.NO_MORE_DOCS; doc = docs.nextDoc() ) {

So I'd say https://hibernate.atlassian.net/browse/HSEARCH-4939 was not completely addressed. I'll reopen it. Could you please have another look? => Ignore this, NO_MORE_DOCS is not NO_MORE_ORDS.

[yrodiere]

Other theory: we don't go through docvalues correctly. I see references to DocIdSetIterator.NO_MORE_DOCS throughout the code, in particularly there:

hibernate-search/backend/lucene/src/main/java/org/hibernate/search/backend/lucene/lowlevel/facet/impl/TextMultiValueFacetCounts.java

Line 179 in 5fccd1a

for ( int doc = docs.nextDoc(); doc != DocIdSetIterator.NO_MORE_DOCS; doc = docs.nextDoc() ) {

Please ignore this, I obviously can't read 😓 It's a different constant.

[marko-bekhta]

Mooooonday 😃
yeah, that's the failed test.... I've tried to run the tests in this module a few times and also the tests from TCK (just in case) but they've passed all the attempts 😔

[yrodiere]

I think there might be a bug there (or in code that relies on this):

hibernate-search/backend/lucene/src/main/java/org/hibernate/search/backend/lucene/lowlevel/docvalues/impl/JoiningTextMultiValuesSource.java

Lines 96 to 99 in 077ac00

	if ( childDocsWithValues.nextChild() != DocIdSetIterator.NO_MORE_DOCS ) {
	nextOrd = values.nextOrd();
	return true;
	}

I'll send a PR.

See https://hibernate.atlassian.net/browse/HSEARCH-4969

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication