Synthetic _source can't be retrieved with overlapping keys in flattened field

[flash1293]

Elasticsearch Version

main

Installed Plugins

No response

Java Version

bundled

OS Version

macOS 15.3

Problem Description

When using flattened fields in a logsdb index, synthetic source is used to reconstruct the value of the flattened field. In case the key/value pairs in the flattened field have an object/scalar mismatch, the search request fails because the _source can't be constructed.

Steps to Reproduce

PUT my-index
{
  "settings": {
    "mode": "logsdb"
  },
  "mappings": {
    "properties": {
        "test": {
            "type": "flattened"
        }
    }
  }
}

POST my-index/_doc
{
  "@timestamp": "2025",
  "test": {
      "nested.doublynested": 123,
      "nested": {
        "doublynested": {
          "gotcha": true
        }
      }
    }
}

GET my-index/_search // returns 500

Logs (if relevant)

failure encoding chunk com.fasterxml.jackson.core.JsonParseException: Duplicate field 'doublynested'
   │       at [Source: (org.elasticsearch.common.io.stream.ByteBufferStreamInput); line: 1, column: 112]
   │      	at com.fasterxml.jackson.core@2.17.2/com.fasterxml.jackson.core.json.JsonReadContext._checkDup(JsonReadContext.java:250)
   │      	at com.fasterxml.jackson.core@2.17.2/com.fasterxml.jackson.core.json.JsonReadContext.setCurrentName(JsonReadContext.java:244)
   │      	at com.fasterxml.jackson.core@2.17.2/com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextToken(UTF8StreamJsonParser.java:758)
   │      	at com.fasterxml.jackson.core@2.17.2/com.fasterxml.jackson.core.JsonGenerator._copyCurrentContents(JsonGenerator.java:2657)
   │      	at com.fasterxml.jackson.core@2.17.2/com.fasterxml.jackson.core.JsonGenerator.copyCurrentStructure(JsonGenerator.java:2638)
   │      	at org.elasticsearch.xcontent.impl@9.1.0-SNAPSHOT/org.elasticsearch.xcontent.provider.json.JsonXContentGenerator.copyCurrentStructure(JsonXContentGenerator.java:540)
   │      	at org.elasticsearch.xcontent.impl@9.1.0-SNAPSHOT/org.elasticsearch.xcontent.provider.json.JsonXContentGenerator.writeRawField(JsonXContentGenerator.java:475)
   │      	at org.elasticsearch.xcontent.impl@9.1.0-SNAPSHOT/org.elasticsearch.xcontent.provider.json.JsonXContentGenerator.writeRawField(JsonXContentGenerator.java:466)
   │      	at org.elasticsearch.xcontent@9.1.0-SNAPSHOT/org.elasticsearch.xcontent.XContentBuilder.rawField(XContentBuilder.java:1205)
   │      	at org.elasticsearch.server@9.1.0-SNAPSHOT/org.elasticsearch.common.xcontent.XContentHelper.writeRawField(XContentHelper.java:578)
   │      	at org.elasticsearch.server@9.1.0-SNAPSHOT/org.elasticsearch.search.SearchHit.toInnerXContent(SearchHit.java:856)
   │      	at org.elasticsearch.server@9.1.0-SNAPSHOT/org.elasticsearch.search.SearchHit.toXContent(SearchHit.java:801)
   │      	at org.elasticsearch.server@9.1.0-SNAPSHOT/org.elasticsearch.rest.ChunkedRestResponseBodyPart$1.encodeChunk(ChunkedRestResponseBodyPart.java:161)
   │      	at org.elasticsearch.server@9.1.0-SNAPSHOT/org.elasticsearch.rest.RestController$EncodedLengthTrackingChunkedRestResponseBodyPart.encodeChunk(RestController.java:1002)
   │      	at org.elasticsearch.transport.netty4@9.1.0-SNAPSHOT/org.elasticsearch.http.netty4.Netty4HttpPipeliningHandler.writeChunk(Netty4HttpPipeliningHandler.java:440)
   │      	at org.elasticsearch.transport.netty4@9.1.0-SNAPSHOT/org.elasticsearch.http.netty4.Netty4HttpPipeliningHandler.doWriteChunkedResponse(Netty4HttpPipeliningHandler.java:267)
   │      	at org.elasticsearch.transport.netty4@9.1.0-SNAPSHOT/org.elasticsearch.http.netty4.Netty4HttpPipeliningHandler.doWrite(Netty4HttpPipeliningHandler.java:235)
   │      	at org.elasticsearch.transport.netty4@9.1.0-SNAPSHOT/org.elasticsearch.http.netty4.Netty4HttpPipeliningHandler.write(Netty4HttpPipeliningHandler.java:188)
   │      	at io.netty.transport@4.1.115.Final/io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:891)
   │      	at io.netty.transport@4.1.115.Final/io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:956)
   │      	at io.netty.transport@4.1.115.Final/io.netty.channel.AbstractChannelHandlerContext$WriteTask.run(AbstractChannelHandlerContext.java:1263)
   │      	at io.netty.common@4.1.115.Final/io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
   │      	at io.netty.common@4.1.115.Final/io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
   │      	at io.netty.common@4.1.115.Final/io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
   │      	at io.netty.transport@4.1.115.Final/io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
   │      	at io.netty.common@4.1.115.Final/io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
   │      	at io.netty.common@4.1.115.Final/io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
   │      	at java.base/java.lang.Thread.run(Thread.java:1575)

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[lkts]

When i test this locally i get this as _source instead of an error for some reason.

"test": {
    "nested": {
        "doublynested": {
            "gotcha": "true"
        }
    }
}

[lkts]

What is the commit you are testing with?

[lkts]

We don't know if a field inside flattened object was "flat" (with dots in the name) or not. We only see the name and have to assume it was an object structure.

This is what is produced as synthetic source before it fails/transforms somewhere later. It does not really make sense.

{
    "@timestamp": "2025-01-01T00:00:00.000Z",
    "test": {
        "nested": {
            "doublynested": "123",
            "doublynested": {
                "gotcha": "true"
            }
        }
    }
}

Is this something you need to rely on? IMO the best we can do now is to document this as not supported. I don't see an easy way to fix this and it is not obvious (at least to me) if this needs to be supported at all.

[flash1293]

This is the version I'm using:

{
  "name": "Joes-MacBook-Pro.local",
  "cluster_name": "elasticsearch",
  "cluster_uuid": "P1VQxqR9TIGGumh3wwYTPQ",
  "version": {
    "number": "9.1.0-SNAPSHOT",
    "build_flavor": "default",
    "build_type": "tar",
    "build_hash": "03271bdfe8b0e469a87fd9be9f8ca1053d7a33d4",
    "build_date": "2025-02-07T03:05:27.318109504Z",
    "build_snapshot": true,
    "lucene_version": "10.1.0",
    "minimum_wire_compatibility_version": "8.19.0",
    "minimum_index_compatibility_version": "8.0.0"
  },
  "tagline": "You Know, for Search"
}

I'm running it as part of the Kibana dev setup (not sure whether that matters)

Is this something you need to rely on? IMO the best we can do now is to document this as not supported. I don't see an easy way to fix this and it is not obvious (at least to me) if this needs to be supported at all.

I don't have a use case for this right now, it's OK for me if not supported. IMHO we shouldn't throw on this, but maybe that's something that already works and my local version is just a little stale.

I could imagine fixing this by detecting the case and flattening fields out only if necessary. But as mentioned, probably not worth it.

[flash1293]

Updated my snapshot and I still get it with this:

{
  "name": "Joes-MacBook-Pro.local",
  "cluster_name": "elasticsearch",
  "cluster_uuid": "s0XVFVkSQa2-fdphMob4Nw",
  "version": {
    "number": "9.1.0-SNAPSHOT",
    "build_flavor": "default",
    "build_type": "tar",
    "build_hash": "54eab9d5646f2d859757f7d38601653b3a06c32a",
    "build_date": "2025-02-17T03:05:42.760076405Z",
    "build_snapshot": true,
    "lucene_version": "10.1.0",
    "minimum_wire_compatibility_version": "8.19.0",
    "minimum_index_compatibility_version": "8.0.0"
  },
  "tagline": "You Know, for Search"
}