Explore Logs: log lines render overlapping / stacked on top of each other after re-running a query

[arturminchukov]

What happened?

In Explore, log lines sometimes render visually overlapping / stacked on top of each other after changing the query and running it again. The text of several log lines is drawn in the same vertical space, making the list unreadable.

The dataset itself is fine — the same response renders correctly after a fresh page load, so this looks like stale virtualization state (cached row heights/offsets) surviving a data change in the new LogList panel.

A similar report exists for 13.0.1: https://community.grafana.com/t/explore-panel-logs-are-stacked-on-each-other/163336.

What did you expect to happen?

Every log line is rendered in its own row, with no visual overlap, regardless of how many times the query is edited and re-run.

How to reproduce

Probably, it appears when you modify the query or load more logs via infinite scroll.

Actual: after a re-run, some log lines are drawn on top of each other.

Expected: the list re-lays out cleanly for the new result set.

Environment

• Grafana: 12.4.3 - security2a
• Datasources: v0.29.0
• Browser: Chrome, firefox

[arturminchukov]

Cannot reproduce the problem.

[mayasnayak]

We're hitting this too, and I captured the DOM while the overlap was on screen. it confirms your hypothesis about stale virtualization state (cached row heights/offsets surviving a data change).

Root cause, from the virtualized row container:

The absolutely-positioned row wrappers have colliding and duplicated top/data-log-index values:

• Two rows share top: 112px (both data-log-index="4"); two share top: 168px (both data-log-index="6").
• The same data-log-index appears at multiple offsets at once, index 2 at top: 1282px, top: 56px, and top: 1320px.

The trigger is mixed row heights. The container holds two conflicting batches: collapsed single-line rows measured at 28px, and expanded pretty-printed JSON rows at 660px (max-height: 638px, with a "show more" button). The virtualizer memoizes heights, measures some rows at 28px and others at 660px, and never reconciles them, so the 660px rows' computed positions collide with leftover 28px slots. That's why a hard refresh (which drops all cached measurements) fixes it, but re-running the query reuses the corrupted cache and it persists/compounds.

DOM snippet (log bodies stripped):

html
<div style="position: absolute; top: 112px; height: 28px; width: 100%;">
  <div data-log-index="4">…collapsed 28px row…</div>
</div>
<div style="position: absolute; top: 112px; height: 28px; width: 100%;">
  <div data-log-index="4">…collapsed 28px row (duplicate top)…</div>
</div>
<div style="position: absolute; top: 0px; height: 660px; width: 100%;">
  <div data-log-index="0">…expanded JSON row, max-height: 638px…</div>
</div>

Environment:

Grafana: v13.1.0 , OSS
Datasource: v0.30.1
Browser: Chrome