# Scripts stored via TransportClient lose fields in source

**URL:** <https://discuss.elastic.co/t/scripts-stored-via-transportclient-lose-fields-in-source/148473>\
**Category:** Elasticsearch\
**Created:** [September 13, 2018, 3:33pm UTC](https://discuss.elastic.co/t/scripts-stored-via-transportclient-lose-fields-in-source/148473 "2018-09-13T15:33:37Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hannes\_Korte](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hannes_korte/32/909_2.png) [@Hannes\_Korte](https://discuss.elastic.co/u/Hannes_Korte)\
**Post date:** [September 13, 2018, 3:33pm UTC](https://discuss.elastic.co/t/scripts-stored-via-transportclient-lose-fields-in-source/148473/1 "2018-09-13T15:33:37Z")

</div>

Hi,

I just discovered a strange behavior of the TransportClient in ES 5.6.11. Maybe a bug, maybe just wrong usage. When I store a script via the TransportClient then all fields but the first field get lost in the source. When I store the same script source via REST it works fine.

I prepared a toy example showing it: [https://gist.github.com/hkorte/cb20352171702446505d6bee693114a3#file-putstoredscriptexample-java-L24](https://gist.github.com/hkorte/cb20352171702446505d6bee693114a3#file-putstoredscriptexample-java-L24)

It starts an ES node in a docker container, stores scripts using transport and REST client and then prints the different results.

Is this a bug or intended behavior?

I know, switching to the REST client would solve the problem. But this is not a trivial task in our production system. Any ideas?

---

<div class="post-metadata">

**Author:** ![rjernst](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rjernst/32/6363_2.png) [@rjernst](https://discuss.elastic.co/u/rjernst)\
**Post date:** [September 13, 2018, 10:55pm UTC](https://discuss.elastic.co/t/scripts-stored-via-transportclient-lose-fields-in-source/148473/2 "2018-09-13T22:55:39Z")

</div>

This sounds like a possible bug in how stored scripts are parsed, but that code has undergone a lot of refactoring since 5.6. In fact, the way you are passing your template (at the root of the request) is deprecated, and just recently removed in master for 7.0. I recommend moving your template inside a `script` element, which is the new way of doing things (so all scripts are the same, whether they are templates or not):

```auto
"script": {
    "lang": mustache",
    "source": { ... your template query }
}

```

---

<div class="post-metadata">

**Author:** ![Hannes\_Korte](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hannes_korte/32/909_2.png) [@Hannes\_Korte](https://discuss.elastic.co/u/Hannes_Korte)\
**Post date:** [September 14, 2018, 12:27pm UTC](https://discuss.elastic.co/t/scripts-stored-via-transportclient-lose-fields-in-source/148473/3 "2018-09-14T12:27:01Z")

</div>

Hi Ryan,

thanks for your suggestion. Actually, it worked wrapping the query inside a script field directly:

```
{
    "script": {
        "query": { "match_all": {} },
        "size": 6
    }
}

```

The Java code looks like this:

```
scriptSource = "{\"query\": {\"match_all\": {}},\"size\": 6}";
transportClient.admin().cluster().preparePutStoredScript()
    .setId("TEST")
    .setLang("mustache")
    .setContent(
            new BytesArray("{\"script\":" + scriptSource + "}"),
            XContentType.JSON
    ).get();

```

Not beautiful, but it works.. 🙂 ..the resulting script is stored as:

```
{
  "_id": "TEST",
  "found": true,
  "script": {
    "lang": "mustache",
    "source": """{"query":{"match_all":{}},"size":6}"""
  }
}

```

Thanks for your help!  
Hannes

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 12, 2018, 12:27pm UTC](https://discuss.elastic.co/t/scripts-stored-via-transportclient-lose-fields-in-source/148473/4 "2018-10-12T12:27:04Z")

</div>

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