DateHistogramAggregationBuilder#toString yields unexpected error string

[yuthura]

Elasticsearch version: 5.3.2

Plugins installed: []

JVM version: 1.8.0_121

OS version: Windows 10

Description of the problem including expected versus actual behavior:

Using toString() on a DateHistogramAggregationBuilder (and most likely other aggregation builders as well) yields the following result:

{ "error" : "JsonGenerationException[Can not write a field name, expecting a value]"}

Expected result is something along the lines of:

{ "my_aggr" : { "date_histogram" : { ... } } }

Steps to reproduce:

Run the following class (adding more calls to the builder continues to yield the same result):

import org.elasticsearch.search.aggregations.AggregationBuilders;

public class Test {
    public static void main(String[] args) {
        System.out.println(
            AggregationBuilders.dateHistogram("revenueHistogram")
        );
    }
}

This is a follow-up on an existing (closed) issue for the following pull request (as request by @cbuescher ): #22280

[cbuescher]

@yuthura yes, thanks for pointing this out. The problem is that ToXContentToBytes#toString(), which is used internally, assumes that the object that should be printed renders to a self-contained json (or yaml, smile...) object, which aggregation builders generally don't do. This is not as easy to fix as in the SuggestionBuilder case you refer to, because AggregationBuilders are all fragments of other json structures.
Note that one way to avoid this is to use XContentHelper.toString(AggregationBuilders.dateHistogram("revenueHistogram") in this example.

[javanna]

@cbuescher Should we make ToXContentToBytes#toString() call XContentHelper#toString or at least behave the same, so that it checks isFragment? I think we may have the problem of breaking output from classes that haven't ben migrated yet to XContentObject although they output a whole object.

[colings86]

@javanna - @cbuescher and I were just saying the same thing. I think that would be the ideal solution here but we need to migrate the remaining classes to XContentObject otherwise we risk fixing this but breaking other classes.

[yuthura]

@cbuescher thanks for the tip on XContentHelper, this solves my use-case for the foreseeable future. :)

[colings86]

This bug is related to #16347 so I'm going to cloase this in favour of that issue