Console: Escaping results in differently stored documents

[spinscale]

Escaping using the three ticks syntax in combination with backslashes can result in differently stored documents (maybe this is documented and I didnt find it, but I think it's worth mentioning somewhere). Take this example

PUT foo/bar/1
{
  "message" : """
*\\!DMAlock*_
"""
}

PUT foo/bar/2
{
  "message" : "*\\!DMAlock*_"
}

GET foo/bar/_mget
{"ids":["1","2"]}

# response
{
  "docs": [
    {
      "_index": "foo",
      "_type": "bar",
      "_id": "1",
      "_version": 3,
      "found": true,
      "_source": {
        "message": """*\\!DMAlock*_"""
      }
    },
    {
      "_index": "foo",
      "_type": "bar",
      "_id": "2",
      "_version": 1,
      "found": true,
      "_source": {
        "message": "*\\!DMAlock*_"
      }
    }
  ]
}

As you can see, the response looks fine. However returning the documents via curl reveal, that the source is actually different

curl -u elastic:changeme localhost:9200/foo/bar/_mget?pretty -d '{"ids":["1","2"]}'
{
  "docs" : [
    {
      "_index" : "foo",
      "_type" : "bar",
      "_id" : "1",
      "_version" : 3,
      "found" : true,
      "_source" : {
        "message" : "*\\\\!DMAlock*_"
      }
    },
    {
      "_index" : "foo",
      "_type" : "bar",
      "_id" : "2",
      "_version" : 1,
      "found" : true,
      "_source" : {
        "message" : "*\\!DMAlock*_"
      }
    }
  ]
}

As you can see the number of backslashes is different, two versus four.

[gmoskovicz]

I think that this is a DevTools issue.

[elasticmachine]

Pinging @elastic/es-ui

[jloleysens]

@spinscale AFAIK this is the intended behaviour of using """ strings. They remove a level of escape sequences which enables, for instance, rendering text with actual new lines instead of \n.

Closing for now.

[cjcenizal]

@jloleysens I'm not quite following -- can you explain why using triple quotes will store \\\\ instead of \\?

[jloleysens]

Given the following two strings:

Without triple quotes:

"This is a string with a newline\nthat is valid JSON"

With triple quotes:

"""This a string with a newline
that is valid JSON"""

When converted to JSON, they will both be: "This is a string with a newline\nthat is valid JSON". This because of how escaped chars are encoded when converted, and as I understand it the intended behaviour. Let me know if there is something I am missing though!

[cjcenizal]

Based on the issue @spinscale reported, it seems like the problem we need to solve is the confusion he experienced, as opposed to something misbehaving on a technical level. Maybe the solution could lie on the technical level (e.g. by changing the way we encode stuff in triple quotes), or maybe it's simply documenting the expected behavior as he suggests. Either way, I think this is still a valid problem we can solve.