Migration to Elasticsearch 6 : request with script and params not working

Elastic Stack Elasticsearch
1

Hello,
I am migrating my Elasticsearch from v5.16 to 6.8 (and after to 7.16) but I have some problem with this type of request (see below) : using params['_source'] in a script
I don't understand why. I didn't find any breakings changes in the documentation. Can you please help me ?
Thanks

{
  "query": {
    "bool": {
      "must": [
        { "match": { "closed": "false" }
        },
        {
          "script": {
            "script": {
              "source": "(params['_source']['evts'] !== null) && (params['_source']['evts']).length > 0",
              "lang": "painless"
            }
          }
        }
      ]
    }
  }}

The response

{
  "took": 6,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 2,
    "skipped": 0,
    "failed": 3,
    "failures": [
      {
        "shard": 1,
        "index": "myIndex",
        "node": "XXX",
        "reason": {
          "type": "script_exception",
          "reason": "runtime error",
          "script_stack": [
            "(params['_source']['evts'] !== null) && (params['_source']['evts']).length > 0",
            "       ^---- HERE"
          ],
          "script": "(params['_source']['evts'] !== null) && (params['_source']['piecesJointes']).length > 0",
          "lang": "painless",
          "caused_by": {
            "type": "null_pointer_exception",
            "reason": "Cannot invoke \"Object.getClass()\" because \"callArgs[0]\" is null"
          }
        }
      }
    ]
  },
  "hits": {
    "total": 0,
    "max_score": null,
    "hits": []
  }
}
2

Hi @drapej,

Source access was removed from several different script contexts including filter scripts transitioning from 5.x to 6.x. At the time our philosophy was to ensure good performance, so we felt that allowing source access in filter/search scripts had hidden performance costs we could not easily make users aware of. Our suggested workaround is to index any data required as part of the documents. If this is not possible when you upgrade to 7.x runtime fields are available that could replicate this behavior, so you could remove the scripts to upgrade to 6.x and then add runtime fields to replace them as part of 7.x.

3

Ok thanks a lot. I will do that

4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.