Axis renders incorrectly for negative values with "Duration" Value format

[garethhumphriesgkc]

Kibana version:
8.12.1

Elasticsearch version:
8.12.1

Server OS version:
Ubuntu 24.04

Browser version:
Chrome 129.0.6668.90

Browser OS version:
Windows 10

Original install method (e.g. download page, yum, from source, etc.):
deb

Describe the bug:
When a Lens visualisation has a dimension which has been configured to be of Value format "Duration", and the chart goes in to negative space, the axis doesn't render values less than 0. The chart itself renders fine, just the axis values are incorrect.

Refer screenshot below.

Steps to reproduce:

1. Create a new lens vis
2. Select a numeric type as the data series
3. Ensure the series has significant negative values (e.g., set the Formula to 0-<field.name>)
4. Observe the axis tick values on the bottom half of the axis are zero

Expected behavior:
Correct values display. Arguably in friendly mode the string "ago" should be appended, but at the least the numbers displayed should reflect the actual values at that horizontal.

Screenshots (if relevant):

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context:

[elasticmachine]

Pinging @elastic/kibana-visualizations (Team:Visualizations)

[nickofthyme]

Hey @garethhumphriesgkc thanks for posting this issue.

The only way I can recreate this is by creating a vis with extremely small values relative to the unit being used so in this case I could show a chart with extends from 0 to -10 Nanoseconds as shown below...

But in reality it's just that the values formatted in an imprecise way using a unit orders of magnitude larger than the values being visualized. So the example above if I were to increase the precision using the Decimals option you could start to see the differences.

With that said, I'm curious what are is the extents of your dataset y values when you see this issue and if the case above explains that.

---

With that said, we do display the same formatted axis label which is incorrect. We do not account for this when rendering the charts so in a way it's up to the user at this point to prevent this as best as possible. We have #170154 to improve this by separating the axis and data formatters.

We have also discussed ways to verify a value is the true and precise value, where if I pass you 0.0001 you return the exact value without rounding. We have opened #170151 to do this for integer values but this is tough to do reliably in all cases and thus we pass this off now to the user.

Finally, we could de-duplicate extract ticks that are the same but we don't always know which ticks are the accurate one. This also has the drawback of removing the sense of scale from the user. For example, imagine the fist chart I posted and removing the -0ms axis tick/label completely.

---

As for this comment...

Arguably in friendly mode the string "ago" should be appended

This is not always the case, durations on their own are simply scalar values and do not always imply direction. You could be trying to visualize the change in request latency over time. In this case the ago/since wording would not apply.

But you are right, this is sometimes the case, which is why we provide the Suffix option under the Lens Value format settings. You are not able to remove the minus sign - from the front, but maybe we could add that as an Absolute option.

[garethhumphriesgkc]

I've just done another repro - as simple as I can. Steps were:

• New dashboard
• Add panel (lens)
• Horizontal axis -> Date histogram -> @timestamp
• Vertical axis -> Pick a numeric metric, then go to formula tab and prepend 0-
• Set "Value format" to "Duration", "Convert" to "Milliseconds", and "To" to "Friendly (precise)"

I get the same behaviour. Interestingly, however, I don't get it for any of the other "To" options - it seems it's limited to "Friendly (precise)". I didn't start from scratch last time, so didn't notice this step was required - sorry.

I've also noticed that sometimes it doesn't matter what the "Convert" is set to at all. Both the axis and tooltip always report values in ms when:

• "Value format" is "duration"
• "To" is "precise"
• Values are negative

While digging deeper, I've also noticed some serious discrepencies in the the charted point as opposed to the values when using the precise mode with "Convert" set to milliseconds or higher, which I don't see with the other modes. Observe below screenshots, which all use the same data - firstly notice the original axis issue this ticket was raised about on the second set, but also notice in the second set that the tooltip values are quite incorrect compared to the bars that supposedly represent them.

Friendly (approximate) - first four values:

Compare to Friendly (precise) - first four values:

The values for the first ten bars here are:

1. -125
2. -455
3. -477
4. -865
5. -507
6. -524
7. -800
8. -547
9. -371
10. -669

Notes:

• Bars 1, 4, and 7 and by far the biggest - at least 10 times bigger than those between them
• Bar 10 is by far the smallest
• Bar 9 is bigger than bar 8

As soon as the 0- is removed and the graph got positive, the numbers change. First ten values in the positive direction are:

1. 4 minutes
2. 12 seconds
3. 12 seconds
4. 4 minutes
5. 13 seconds
6. 13 seconds
7. 4 minutes
8. 13 seconds
9. 15 seconds
10. 2 seconds

This matches all other "To" modes (both positive and negative) and looks much closer to the actual bar lengths (although there are 15 different lenth bars all claiming to be "4 minutes", so "precise" has a somewhat fuzzy definition).

In summary, negative values used for a duration with millisecond or higher precision aren't calculated correctly in "Friendly (precise)" output mode.

[nickofthyme]

Attempting to reproduce this with your updated steps, using an 8.12.1 cluster, the same data value, from the dashboard exactly as you describe -- I cannot see the results you are showing. See recording below...

Zight.Recording.2024-10-17.at.12.42.28.PM.mp4

Notice how the values are the same for positive and negative when stacked on top of each other. There is an issue with the bottom-most tick always showing 0ms which is another bug which has since been fixed.

Expand for data used

POST _bulk
{ "index" : { "_index" : "test-neg-values", "_id" : "1" } }
{ "test_metric": 125, "@timestamp": "2024-10-17T20:30:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "2" } }
{ "test_metric": 455, "@timestamp": "2024-10-17T20:31:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "3" } }
{ "test_metric": 477, "@timestamp": "2024-10-17T20:32:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "4" } }
{ "test_metric": 865, "@timestamp": "2024-10-17T20:33:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "5" } }
{ "test_metric": 507, "@timestamp": "2024-10-17T20:34:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "6" } }
{ "test_metric": 524, "@timestamp": "2024-10-17T20:35:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "7" } }
{ "test_metric": 800, "@timestamp": "2024-10-17T20:36:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "8" } }
{ "test_metric": 547, "@timestamp": "2024-10-17T20:37:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "9" } }
{ "test_metric": 371, "@timestamp": "2024-10-17T20:38:00.000Z" }
{ "index" : { "_index" : "test-neg-values", "_id" : "10" } }
{ "test_metric": 669, "@timestamp": "2024-10-17T20:39:00.000Z" }

---

Could you provide me a few things so I can try to figure this out? First thing would be to share the response from the Inspect tab. See recording below for how to get this...

Zight.Recording.2024-10-17.at.12.50.38.PM.mp4

The second thing would be the saved object of the dashboard. See video of how to do this below, also make sure the Include related objects option is enabled before exporting. Ideally this dashboard has just the problematic visualization.

Zight.Recording.2024-10-17.at.12.54.45.PM.mp4

Warning

Please be sure to remove/replace any personal data you do not wish to share publicly.

[garethhumphriesgkc]

Hi,

Please see attached data:

• Inspector_raw.csv - The output of an affected visualisation's Inspect -> Download CSV -> Raw CSV
• Inspector_formatted.csv - The output of an affected visualisation's Inspect -> Download CSV -> Formatted CSV
• request.txt - The output of an affected visualisation's Inspect -> View: Requests -> Request
• response.txt - The output of an affected visualisation's Inspect -> View: Requests -> Response
• load.tsv - a TSV file containing data which I can use to demonstrate the issue

I loaded the data in load.tsv in to a brand new index, followed the steps outlined, and got the unexpected behaviour. I also loaded it into an 8.15.1 cluster and did not get the same behaviour - so it appears to be limited to either 8.12.1 or some other configuration unique to this cluster (but not this index). I will continue looking for more discrepencies.

Note that there is a runtime field in the request which is an obvious candidate for testing - this was absent in the test index and I still saw the issue, so have eliminated it as a cause.
Inspector_raw.csv
Inspector_formatted.csv
request.txt
response.txt
load.tsv.txt

[garethhumphriesgkc]

• dashboard_test-neg-values.ndjson - Dashboard definition
  dashboard_test-neg-values.ndjson.txt