Percolator gets confused when query is added as a document that is not of .percolator type

[ppf2]

It appears that the percolator gets confused and does not return a match after the first percolator query
if queries are unintentionally added as documents instead of percolator queries. eg.

DELETE /twitter

# register FIRST percolator query
PUT /twitter/.percolator/FIRST
{
    "query" : {
        "match" : {
            "message" : "FIRST"
        }
    }
}

# create a document with the same query in the body
PUT /twitter/foo/FIRST_DOC
{
    "query" : {
        "match" : {
            "message" : "FIRST"
        }
    }
}
# register SECOND percolator query
PUT /twitter/.percolator/SECOND
{
    "query" : {
        "match" : {
            "message" : "SECOND"
        }
    }
}
# create a document with the same query in the body
PUT /twitter/foo/SECOND_DOC
{
    "query" : {
        "match" : {
            "message" : "SECOND"
        }
    }
}
# register THIRD percolator query
PUT /twitter/.percolator/THIRD
{
    "query" : {
        "match" : {
            "message" : "THIRD"
        }
    }
}
# create a document with the same query in the body
PUT /twitter/foo/THIRD_DOC
{
    "query" : {
        "match" : {
            "message" : "THIRD"
        }
    }
}

# Match found
GET /twitter/test/_percolate
{
  "doc":{
    "message":"FIRST"
  }
}

# Match not found
GET /twitter/test/_percolate
{
  "doc":{
    "message":"SECOND"
  }
}

# Match not found
GET /twitter/test/_percolate
{
  "doc":{
    "message":"THIRD"
  }
}

[martijnvg]

@ppf2 The reason that second and third percolator queries don't match is because of a mapping issue. When the first percolator query is parsed there is no message field, so it just uses the field name message (even though there is no mapping for it). When the second and third query are parsed there is a message field (query.match.message) which was introduced by the document indexed before and it uses that the field for the match query in the percolator document.

There have been many mapping related issues with the percolator and because of this since 1.4.0.beta1 a field mapping needs to exist otherwise the indexing of a percolator query fails: #6928

So in this particular case if the message field is defined before adding a percolator query then the percolate requests do match with the previous added percolator queries.

[clintongormley]

The fix in #6928 and requiring unambiguous field names (see #4081) will avoid this problem. Closing.