New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Field keys returning from server come back in wrong order #1158

Closed
jaredscheib opened this Issue Apr 3, 2017 · 9 comments

Comments

Projects
None yet
6 participants
@jaredscheib
Contributor

jaredscheib commented Apr 3, 2017

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

@nhaugo nhaugo added this to the 1.2.0-beta8 milestone Apr 3, 2017

@nhaugo nhaugo self-assigned this Apr 4, 2017

@nhaugo nhaugo added the ready label Apr 4, 2017

@nhaugo nhaugo modified the milestones: 1.2.0-beta9, 1.2.0-beta8 Apr 6, 2017

@jaredscheib

This comment has been minimized.

Show comment
Hide comment
@jaredscheib

jaredscheib Apr 7, 2017

Contributor

@jackzampolin is interested in this outcome as well.

Contributor

jaredscheib commented Apr 7, 2017

@jackzampolin is interested in this outcome as well.

@nhaugo nhaugo modified the milestones: 1.2.0-beta10, 1.2.0-beta9 Apr 21, 2017

@nhaugo

This comment has been minimized.

Show comment
Hide comment
@nhaugo

nhaugo Apr 28, 2017

Contributor

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

Contributor

nhaugo commented Apr 28, 2017

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 nhaugo changed the title from Decide and fix which single stat is displayed to Display single stat as the first field requested. Apr 28, 2017

@nhaugo

This comment has been minimized.

Show comment
Hide comment
@nhaugo

nhaugo Apr 28, 2017

Contributor

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

Contributor

nhaugo commented Apr 28, 2017

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

@rkuchan

This comment has been minimized.

Show comment
Hide comment
@rkuchan

rkuchan Apr 28, 2017

Contributor

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

Contributor

rkuchan commented Apr 28, 2017

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

@nhaugo nhaugo modified the milestones: 1.3.0, 1.2.0-beta10 Apr 28, 2017

@nhaugo nhaugo added the bug label May 2, 2017

@timraymond

This comment has been minimized.

Show comment
Hide comment
@timraymond

timraymond May 3, 2017

Contributor

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

Screencap showing desired behavior

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.

Contributor

timraymond commented May 3, 2017

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

Screencap showing desired behavior

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

This comment has been minimized.

Show comment
Hide comment
@lukevmorris

lukevmorris May 4, 2017

Contributor

@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.

Contributor

lukevmorris commented May 4, 2017

@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.

@lukevmorris lukevmorris changed the title from Display single stat as the first field requested. to Field keys returning from server come back in wrong order May 4, 2017

@nhaugo nhaugo removed their assignment May 5, 2017

@lukevmorris lukevmorris added in progress and removed ready labels May 5, 2017

@lukevmorris lukevmorris self-assigned this May 5, 2017

@nhaugo nhaugo modified the milestones: 1.3.1, 1.3.0 May 8, 2017

@nhaugo

This comment has been minimized.

Show comment
Hide comment
@nhaugo

nhaugo May 8, 2017

Contributor

@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

Contributor

nhaugo commented May 8, 2017

@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

@rkuchan rkuchan referenced this issue May 8, 2017

Merged

[Chronograf] v1.3 documentation #1106

35 of 35 tasks complete

@nhaugo nhaugo assigned nhaugo and unassigned lukevmorris May 15, 2017

@nhaugo nhaugo modified the milestones: 1.3.2, 1.3.1 May 15, 2017

@nhaugo nhaugo added ready and removed in progress labels May 15, 2017

@jaredscheib

This comment has been minimized.

Show comment
Hide comment
@jaredscheib

jaredscheib May 22, 2017

Contributor

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?

Contributor

jaredscheib commented May 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jaredscheib

jaredscheib May 23, 2017

Contributor

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

Contributor

jaredscheib commented May 23, 2017

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

@goller goller added delivered and removed ready for review labels May 23, 2017

@nhaugo nhaugo closed this May 25, 2017

@nhaugo nhaugo removed the delivered label May 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment