Chronograf: Field keys returning from server come back in wrong order

[jaredscheib]

If there is more than one query, a different single stat is currently displayed under different conditions or on different pages, for a cell.

[jaredscheib]

@jackzampolin is interested in this outcome as well.

[nhaugo]

The is multiple fields are selected the first in the list should always be what is display as the single stat, e.g. SELECT foo,bar,baz from cpu.

The single stat should aways be "foo" in this case.

@jackzampolin thoughts

[nhaugo]

@rkuchan Do we have info about the viz types in the docs, if so we will want to document this behavior.

[rkuchan]

I'll make sure to add this to the Dashboard guide

[timraymond]

Using the first field appears to be the current behavior when creating a single stat:

For fields A and B, I first added A, then B, removed A, added A, then removed B to arrive at the initial state. It displays the first field in the query.

I think this can be closed unless someone can provide repro steps showing otherwise.

[lukevmorris]

@timraymond After further diagnosis, it appears that Single Stat is behaving as expected. Given a query with two fields, it will display the most current value for the first field.

However, occasionally when saving changes to a cell, the field keys in the queryConfig will come back from the server in a different order than when they were submitted. This means that if we submit

SELECT "usage_idle", "usage_user" FROM ...

it's possible to receive

SELECT "usage_user", "usage_idle" FROM ...

When validating the query at /sources/1/queries, the fields come back in the same order.
But when PATCHing a cell, the fields can come back in a different order.

This means that you may see one stat in the CEO but another stat when returning to the dashboard.

[nhaugo]

@rkuchan can we put in the known issues that single-stat graphs with custom time ranges will return inconsistent results if there are multiple fields in the query.

The work around is to use dashTime or to only return a single field from the query for single stat graphs

[jaredscheib]

What is the current desired path forward with this, engineering-wise? We _could_ ensure order client-side, regardless of the order that the server sends data back in. Thoughts?

[jaredscheib]

Turns out the order was randomized by using map on the server-side, so we changed this to preserve order.