Hi@Kubik42, I've created a changelog YAML for you.

The reason for failing tests ishere. Whenever there is noFieldExtractPreference (ie.FieldExtractPreference.NONE, just like in the SDH),geo_points are mapped toBytesRef. This means that when the block loader sanity checker runs, it expects the underlying element type to beBytesRef. However, since we've now started to rely on doc_values, the type is actuallyLONG.

Perhaps the bigger problem here is thatNONE is being assigned whenDOC_VALUES should be the one being assigned. This would normally not be an issue since field types generally use the same underlying types for storing values, regardless of whether they're using doc_values vs stored fields. However, geo_points are special and the way we store them changes. More specifically, if doc_values are available, we store them asLongs and when the stored flag is toggled, we store them asBytesRef; although technically itsStrings, but more on that later.

In my rabbit hole of understanding how BlockLoaders work, I found a somewhat of a bug thats in main. When ageo_point is specified withstore = true anddoc_values = false, we end up returning an imprecise result.

For example, the following command fails:

./gradlew ":x-pack:plugin:logsdb:yamlRestTest" --tests "org.elasticsearch.xpack.logsdb.LogsdbTestSuiteIT.test {yaml=/51_esql_synthetic_source/Simple from}" -Dtests.seed=76E814C77C112204 -Dtests.locale=xh -Dtests.timezone=Europe/Saratov -Druntime.java=25

with:

        Expected: "POINT (-74.00600004941225 40.712799984030426)"             but: was "POINT (-74.006 40.7128)"            at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)            at org.junit.Assert.assertThat(Assert.java:964)            at org.junit.Assert.assertThat(Assert.java:930)            at org.elasticsearch.test.rest.yaml.section.MatchAssertion.doAssert(MatchAssertion.java:100)            at org.elasticsearch.test.rest.yaml.section.Assertion.execute(Assertion.java:68)            at org.elasticsearch.test.rest.yaml.ESClientYamlSuiteTestCase.executeSection(ESClientYamlSuiteTestCase.java:522)            ... 41 more

Based on what I've read in the code, this precision loss isexpected. That being said, its not documentedpublicly.

There is also a problem with usingBlockStoredFieldsReader.BytesFromStringsBlockLoader(name()) even when the field is stored. This is despite the fact that during indexing, theStoredField is created with a String representation of the geo_point;code.

When block loading, I get the error:Unknown geometry type: 825699888, which comes fromhere.

My guess is that it has something to do with the geo_point being stored as a String, rather than being converted to WKT first. That said, even when I usedWellKnownText.toWKT() I still received a similar error -Unknown geometry type: 1414416719.

For now, I've just followed what we do inGeoShapeWithDocValuesFieldMapper and changed the block loader toBlockStoredFieldsReader.BytesFromBytesRefsBlockLoader, which has worked.

This needs further discussion.

I did a little more investigating and found that the reason we end up withFieldExtractPreference.NONE is because we initializeFieldExtractExechere, where bothdocValuesAttributes andboundsAttributes are empty sets. This leads to thefollowing check failing, which ultimately returnsdefaultPreference, which isFieldExtractPreference.NONE.

This got me thinking, why are we setting the preference toNONE for attributes with doc_values? Shouldn't it beDOC_VALUES? If we think about it,NONE implies we can load the values however we want, so we're not restricted to using doc_values for that. This made me notice that insidethis function, the attribute itself contains aDataType, which in turns exposeshasDocValues(). So, ultimately, wouldn't it make more sense to just do:

if (docValuesAttributes.contains(attr) || attr.dataType().hasDocValues()) {    return MappedFieldType.FieldExtractPreference.DOC_VALUES;}

However, doing so causes some type inequality exceptions.

Nhat pointed outthis code, which suggests that doc_values shouldn't be always be used. However, that conflicts with the definition ofFieldExtractPreference.NONE, which states that we can use anything.