well I don't think it shoudl throw a NPE but on the other hand why whould you want to aggregate on a suggest field. you should use multi field for this IMO. @jpountz can you take a look at this NPE and provide a better error message?

If I understand correctly, currently the completion suggester creates a field (called "domain") in the above example which contains the content of "input" and is searchable but one cannot aggregate, because of the special format of this type ( @jpountz please correct if I am wrong). A better error message would be useful.

you should use multi field for this IMO.

It is unclear to me how multi_field can be used with the suggester here. The documentation is not too explicit:

Even though you are losing most of the features of the completion suggest, you can opt in for the shortest form, which even allows you to use inside of multi fields. But keep in mind, that you will not be able to use several inputs, an output, payloads or weights.

I would have expected multi_field to work like this:

{
   "domain": {
      "type": "multi_field",
      "fields": {
         "domain": {
            "max_input_length": 50,
            "preserve_separators": true,
            "payloads": false,
            "analyzer": "simple",
            "preserve_position_increments": true,
            "type": "completion"
         },
         "input": {
            "type": "string"
         }
      }
   }
}

and then expected that aggregation would work on "domain.input". Is that supposed to work so so? If so, I think it is broken.

In any case, it might be nice to have an option to make all parameter fields searchable and and also allow aggregations on them. Currently, the only way to do this seems to be to add the parameters to a field with a different name than the suggestion field. Instead, suggester could create these fields automatically if the user wants to. We could have something like:

{
   "domain": {
      "max_input_length": 50,
      "preserve_separators": true,
      "payloads": false,
      "analyzer": "simple",
      "preserve_position_increments": true,
      "type": "completion",
      "input": {
              # Here be whatever the user likes to configure for indexing
      },
      "output": {
             ...
      },
      ...
   }
}

which would cause creation of fields "domain.input", "domain.output" and so on with user defined indexing options.

Does that make sense?

I tried multi_fiield and it works as what I wanted.
The mapping I use is similar to what @brwe mentioned.

{
   "domain": {
      "type": "multi_field",
      "fields": {
         "domain": {
            "max_input_length": 50,
            "preserve_separators": true,
            "payloads": false,
            "analyzer": "simple",
            "preserve_position_increments": true,
            "type": "completion"
         },
         "input": {
            "type": "string"
         }
      }
   }
}

Thank you for the hint @s1monw .

@brwe I just tried a multi-field setup, and this seems to work fine:

DELETE /test

PUT /test
{
    "mappings": {
        "test": {
            "properties": {
                "my_field": {
                    "type": "completion",
                    "analyzer": "simple",
                    "fields": {
                        "raw": {
                            "type": "string",
                            "index": "not_analyzed"
                        }
                    }
                }
            }
        }
    }
}

PUT /test/test/1
{
    "my_field": "foo bar"
}

PUT /test/test/2
{
    "my_field": "foo bar baz"
}

POST /test/_refresh

GET /test/_suggest
{
    "my-suggest" : {
        "text" : "foo b",
        "completion" : {
            "field" : "my_field"
        }
    }
}

GET /test/_search
{
    "aggs": {
        "my_field_values": {
            "terms": {
                "field": "my_field.raw"
            }
        }
    }
}

Adding capabilities to store domain.input and domain.output as you describe feels to me like reinventing multi-fields. I think we should rather fix the error message when trying to aggregate on a completion field and recommend on either indexing the field twice (eg. if you need to specify input and output separately) or using a multi-field as above for the simple cases.

Ah! Now I get it. I was trying out how this works when you explicitly provide "input" and "output" when indexing. I guess this is meant by "opt in for the shortest form".
Thanks for clarifying that this is not what was meant!

I think we should rather fix the error message

Ok, I'l just add the more descriptive error message.

@brwe can you port this to 1.1.2?

done