Repository navigation
fix: keep time chart series colors stable across refreshes #3646
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| --- | ||
| '@hyperdx/app': patch | ||
| --- | ||
|
|
||
| fix: time chart series keep the same color across refreshes; series are now | ||
| ordered by name instead of by the order ClickHouse returned them |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -869,10 +869,18 @@ export function formatResponseForTimeChart({ | |
| } | ||
|
|
||
| const logLevelColorOrder = getLogLevelColorOrder(); | ||
| // Series are otherwise ordered by first appearance in the response, which | ||
| // ClickHouse does not keep stable between runs. Colors are assigned by | ||
| // position, so tie-break by key to keep each series' color stable. | ||
| let sortedLineData = Object.values(lineDataMap).sort((a, b) => { | ||
| return ( | ||
| logLevelColorOrder.findIndex(color => color === a.color) - | ||
| logLevelColorOrder.findIndex(color => color === b.color) | ||
| logLevelColorOrder.findIndex(color => color === b.color) || | ||
| (a.currentPeriodKey < b.currentPeriodKey | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🔵 minor — Comparing strings with
Advisory. Fix if it is a small defect in code this PR changes; otherwise reply in the thread. Do not widen the PR or touch files it did not already change. How to respond |
||
| ? -1 | ||
| : a.currentPeriodKey > b.currentPeriodKey | ||
| ? 1 | ||
| : 0) | ||
| ); | ||
| }); | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟠 major — Colours still depend on position, so they shift whenever the set of series changes
Sorting fixes colours only when the same series come back in a different order.
setLineColors(ChartUtils.tsx:637) still hands outcolorIndex++by position, and the set of series often changes when the user moves the time window, which is the repro in the PR description. Example: refresh 1 returns cart, checkout, email, so checkout gets COLORS[1]. Refresh 2 has no rows forcart, so checkout moves to COLORS[0] and email to COLORS[1]. ThemaxSeriescap causes the same shift when the kept top-N changes. To make a series' colour independent of what else is in the result, pick the palette index from the series key, e.g.hashCode(currentPeriodKey)from@hyperdx/common-utils/dist/core/utilsmodulo the palette size. Add a test where one series is missing from the second response.Nothing blocks merge automatically, but a maintainer will expect this fixed if it is a real defect in code this PR changes. If it is about surrounding code, reply and say so instead of patching. Do not widen the PR. How to respond