Apache Pinot

Hi all, this might not be the correct channel to discuss this, in which case, please point me in the right direction.

I was just wondering if anyone knows why the `traceInfo` value returned when querying Pinot via the ReST API is an escaped string of JSON, as opposed to an actual JSON value?

Can’t think of a reason why it has to be escaped. File a GH issue?

<@U04DA4QRA15> Do you have a sample or a snapshot ?

<@U03JSC3AZ8D>

Example from a response:
```"traceInfo": {
        "172.17.0.2_O": "[{\"0\":[{\"SelectionQuerySegmentPruner Time\":1},{\"SegmentPrunerService Time\":2},{\"CombinePlanNode Time\":1},{\"SelectionOnlyCombineOperator Time\":62},{\"InstanceResponseOperator Time\":62}]},{\"0_0\":[{\"MatchAllFilterOperator Time\":5},{\"DocIdSetOperator Time\":8},{\"ProjectionOperator Time\":13},{\"PassThroughTransformOperator Time\":13},{\"ProjectionBlockValSet Time\":33},{\"SelectionOnlyOperator Time\":58}]}]"
    },```
I’m happy to raise a PR to change this such that it returns a proper JSON value as opposed to a string of JSON; I just wanted to ask if there was a reason for this design choice first.

It’s a little annoying when decoding the response in an internal client we are building, hence me looking into raising a PR to change this.

You might want to implement it in a backward compatible way (may be add a param to enable previous behavior). 

I’m happy to do that if that’s preferred, my only concern would be whether this was a conscious design choice or not. I don’t see the benefit in returning a string of JSON over a true JSON object which personally signals to me this was not a conscious decision. If it _wasn’t_ a conscious decision I’d actually consider this a bug as it prevents easy decoding of the overall response JSON, and wouldn’t hide this behind a flag. If it was a conscious decision I’d be interested to understand why. Happy to discuss this on the PR when I get around to raising one (won’t be this week)

Yeah, I can’t think of a reason why it would be a conscious design choice. Further discussions can/should happen on the PR with broader audience. Thanks again for offering your help, much appreciated.