Describe the bug
In the Trace tab of an event side panel, the span bars in the waterfall chart are not rendered proportionally to their actual durations once the timeline has been zoomed in. Very short spans (e.g. 14 ms) end up rendered as wide as, or wider than, spans that are hundreds of times longer (e.g. 2.4 s), which makes the waterfall misleading to read.
Inspecting one of the affected span bars in DevTools shows an inline style roughly like:
min-width: 24.200000%;
width: 24.200000%;
The same percentage appears on both short and long spans, so duration information is effectively lost in the bar widths.
Steps to reproduce
- Open any trace that contains at least one long span (~seconds) and several very short spans (tens of ms or less). The example in my screenshot has 414 spans across ~8 s, with some 14 ms
INSERT / UPDATE spans.
- Open the event side panel for any span in that trace and switch to the Trace tab.
- Hover the waterfall area and scroll to zoom in horizontally a few times (or drag to pan + zoom until the bars get noticeably wider).
- Observe the bars for the very short spans (14 ms in my case): they grow to the same visual width as multi-second spans.
- Inspect one of the short span bars — its inline
min-width / width is a large percentage (e.g. 24.2%) regardless of the span's real duration.
Expected behavior
Span bar widths in the waterfall should remain proportional to their durations at every zoom level. A short span should stay visually short relative to a long span, even after zooming in. (A small floor so that sub-pixel spans remain clickable is fine, but it should not scale with the zoom factor.)
Actual behavior
After zooming in, short spans are rendered with the same width as a much longer span. The waterfall no longer reflects actual durations, which defeats the purpose of the visualisation when investigating latency.
Screenshot
before zoom
after zoom
Environment
- HyperDX: v2.23.0
- Browser: latest Firefox on latest macOS
- Deployment:
Additional context
- Only the Trace waterfall tab is affected; the bar widths look correct at the default zoom level and only diverge after zooming.
- Reproducible with any trace that mixes very short and long spans.
This issue report was drafted with the assistance of an AI coding agent (based on my own reproduction and screenshots). The technical content has been reviewed by me before submission.
Describe the bug
In the Trace tab of an event side panel, the span bars in the waterfall chart are not rendered proportionally to their actual durations once the timeline has been zoomed in. Very short spans (e.g. 14 ms) end up rendered as wide as, or wider than, spans that are hundreds of times longer (e.g. 2.4 s), which makes the waterfall misleading to read.
Inspecting one of the affected span bars in DevTools shows an inline style roughly like:
The same percentage appears on both short and long spans, so duration information is effectively lost in the bar widths.
Steps to reproduce
INSERT/UPDATEspans.min-width/widthis a large percentage (e.g.24.2%) regardless of the span's real duration.Expected behavior
Span bar widths in the waterfall should remain proportional to their durations at every zoom level. A short span should stay visually short relative to a long span, even after zooming in. (A small floor so that sub-pixel spans remain clickable is fine, but it should not scale with the zoom factor.)
Actual behavior
After zooming in, short spans are rendered with the same width as a much longer span. The waterfall no longer reflects actual durations, which defeats the purpose of the visualisation when investigating latency.
Screenshot
before zoom
after zoom
Environment
Additional context
This issue report was drafted with the assistance of an AI coding agent (based on my own reproduction and screenshots). The technical content has been reviewed by me before submission.