Indexing completion type fields with multi-fields fails

[underyx]

Edit: As it turns out, the issue I originally had was expected behavior, but it would be better if mappings like this would be rejected when someone tries to set them, so I'm leaving the original issue text below:

I'm trying to specify a field like this in 2.1.0:

...
"city": {
    "type": "completion",
    "preserve_separators": false,
    "payloads": true,
    "fields": {
        "analyzed": {
            "type": "completion",
            "analyzer": "standard",
            "payloads": true,
        }
    }
}
...

Indexing seems to be okay, but when searching, I get an error saying that "Field [city.analyzed] is not a completion suggest field". Am I wrong to expect this to work?

[clintongormley]

Hi @underyx

Completion fields shouldn't support multi-fields, because a completion field can accept a structured object which wouldn't work with (eg) a string subfield. I've marked this as a bug because we should complain about this at mapping time.

[underyx]

I see, thank you, @clintongormley!

[javanna]

@elastic/es-search-aggs

[pgomulka]

Hi,
I was trying to reproduce that issue with the oldest version supported 5.2.1 (same for the 6.4) , and it is not possible to index a document with a multi-field of completion type.

It is however still possible to create a mapping with multi-fields of type completion. Should this be prevented?

curl --request PUT \
  --url http://localhost:9200/cities \
  --header 'content-type: application/json' 
>>
{"acknowledged":true,"shards_acknowledged":true}

curl --request PUT \
  --url http://localhost:9200/cities/citytype/_mapping \
  --header 'content-type: application/json' \
  --data '
{
  "citytype" : {
        "properties" : {
            "city" : { 
                "type": "completion",
                            "preserve_separators": false,
                            "fields": {
                                    "analyzed": {
                                            "type": "completion",
                                            "analyzer": "standard"
                                    }
                            }
            }
        }
    }
}'
{"acknowledged":true}

curl --request PUT \
  --url http://localhost:9200/cities/citytype/1 \
  --header 'content-type: application/json' \
  --data '
{
    "city" : {
        "input": [ "Krak", "Cracow" ],
        "weight" : 34
    }
}’
>>
{
    "error": {
        "root_cause": [
            {
                "type": "parse_exception",
                "reason": "failed to parse expected text or object gotEND_OBJECT"
            }
        ],
        "type": "mapper_parsing_exception",
        "reason": "failed to parse",
        "caused_by": {
            "type": "parse_exception",
            "reason": "failed to parse expected text or object gotEND_OBJECT"
        }
    },
    "status": 400
}

See gist with curl requests and responses
https://gist.github.com/pgomulka/d3444a8ea93f0672392fb518aaacc839

[pgomulka]

Creating documents on mappings with completion type fields with multi-fields fails when the document is provided with completion field in a form of array or object. This is because sub multi-field of different then completion type is not able to parse that format.

curl --request PUT \
  --url http://localhost:9200/citiesx2 \
  --header 'content-type: application/json' \
  --data '
{
  "mappings": {
    "citytype": {
      "properties": {
        "city": {
          "type": "completion",
          "preserve_separators": false,
          "fields": {
            "analyzed": {
              "type": "keyword"
            }
          }
        }
      }
    }
  }
}
'

curl --request PUT --url http://localhost:9200/citiesx2/citytype/12 --header 'content-type: application/json’ --data '
{
  "city" : {
        "input":["New york", "NY"],
        "weight": 34
    }
}
>>>
{
    "error": {
        "root_cause": [
            {
                "type": "mapper_parsing_exception",
                "reason": "failed to parse [city.analyzed]"
            }
        ],
        "type": "mapper_parsing_exception",
        "reason": "failed to parse [city.analyzed]",
        "caused_by": {
            "type": "illegal_state_exception",
            "reason": "Can't get text on a END_OBJECT at 6:2"
        }
    },
    "status": 400
}

Sub multi-field of type completion, fails due to reusing a context with a parser being already at the end of the object.

curl --request PUT \
  --url http://localhost:9200/subfieldcompletion \
  --header 'content-type: application/json' \
  --data '
{
  "mappings": {
    "citytype": {
      "properties": {
        "city": {
          "type": "completion",
          "preserve_separators": false,
          "fields": {
            "analyzed": {
              "type": "completion"
            }
          }
        }
      }
    }
  }
}
’

curl --request PUT \
  --url http://localhost:9200/subfieldcompletion/citytype/12 \
  --header 'content-type: application/json' \
  --data '
{
  "city"  : {
        "input": [ “New York", “NY" ],
        "weight" : 34
    }
}’
>>
{
    "error": {
        "root_cause": [
            {
                "type": "parse_exception",
                "reason": "failed to parse expected text or object gotEND_OBJECT"
            }
        ],
        "type": "mapper_parsing_exception",
        "reason": "failed to parse",
        "caused_by": {
            "type": "parse_exception",
            "reason": "failed to parse expected text or object gotEND_OBJECT"
        }
    },
    "status": 400
}

The issue was initially created to prevent mappings with completion type fields with multi-field. However we already support that, it works fine when indexing document with completion type field in String format.

curl --request PUT \
  --url http://localhost:9200/subfieldcompletion2/citytype/12 \
  --header 'content-type: application/json' \
  --data '
{
  "city"  : "New York"
}'

It is possible to fix that by modifying the CompletionFieldMapper to provide multiFields mapper with a context with already parsed externalValue. Also The CompletionFieldMapper itself, should support externalValues from context (it is not at the moment)
Will create a PR with a fix instead of validation shortly.