Auto-indenting Console requests converts triple-quoted strings to escaped quotes

[cjcenizal]

To reproduce, enter this input:

PUT bar/_doc/1
{
  "content": """trip"le"""
}

Auto-indent this request and it will be converted to:

PUT bar/_doc/1
{
  "content": "trip\"le"
}

Ideally, triple-quoted strings should remain triple-quoted.

[elasticmachine]

Pinging @elastic/es-ui

[jloleysens]

@cjcenizal Looking at the code on this, it looks like this behaviour may be a feature not a bug 😅 . That is if you've formatted it once, and format it again you should be seeing

{"content": "trip\"le"}
// =>
{
  "content": """trip"le"""
}
...

The idea probably being that if you want to have the body in a format you can paste into a non-triple quote friendly environment you can. If this is something we want to change (I do find this toggling a bit strange tbh) then perhaps we can discuss some alternative behaviour that would work best? Are you think de-indent but keep the """?

[jloleysens]

@cjcenizal After messing around with this a bit I see that I misunderstood what you meant. The indentation toggle is something else - I was able to reproduce what you were describing though :). Including this fix here: #44646

[cjcenizal]

@bleskes Do you know if the behavior described in this PR description is intended?

[bleskes]

that sounds broken to me. I did have some minimums for automatically using """ - I think I had some minimal length requirement, of a maximum number of escaping. The thinking is that short strings can be consumed raw

[EmilBode]

Something else is broken the other way around:
Escaped quotes that should not be triple-quoted are.
I'm on 7.3 downloaded several weeks ago, and able to reproduce the original problem

Except when I use a different string, starting and ending with an escaped double quote:

PUT bar/_doc/1
{
  "content": "\"triple\""
}

auto-indents gives me here:

PUT bar/_doc/1
{
  "content": """"triple""""
}

Which generates an error, as we now have something starting and ending with four quotes, which is interpreted as a string "triple, followed by an unexpected extra double quote.

But I haven't tested this with the new patch yet.

[jloleysens]

Hi @EmilBode thanks for reporting this! What you've described is a separate issue unfortunately and I could reproduce this in current master. I'll open another issue to make tracking this a bit cleaner.