finding(plugin-charts): funnel and pie handed all-zero rows render a pixel-identical blank tile — same silence as #7140, a different trigger

[os-warren]

Filed unassigned by the implementer of #7140 (PR #7146) while measuring the sankey blank. ⛔ Out of scope there and deliberately not fixed in that PR — different trigger, different arm, and a different mechanism.

The measurement

Twelve chart tiles were rendered in a real Chromium at origin/main e8e4c4d, each in a 520x240 box, and every tile's screenshot was hashed. Five hashed identical to one another — b53cc8c42c5341541399eab3475163d0, a tile with nothing on it:

tile	descendants	svg	screenshot hash
sankey, every measure 0	1	0	b53cc8c4…
sankey, every measure null	1	0	b53cc8c4…
sankey, every measure negative	1	0	b53cc8c4…
funnel, every measure 0	34	1	b53cc8c4…
pie, every measure 0	31	1	b53cc8c4…
bar, every measure 0 (CONTROL)	104	1	81bbfc97… — axes, ticks, labels, legend
sankey, all values positive (CONTROL)	26	1	d9dabc9b… — a sankey

The controls hash differently, so the instrument returns non-zero on the same page and the five zeros are real.

Why this is NOT #7140

#7140's sankey blank is an empty DOM — the arm returns a bare div, one element, no svg. PR #7146 fixes that by rendering the file's ChartRefusal shell instead.

Funnel and pie are the opposite shape and are untouched by that fix: their DOM is rich (34 and 31 descendants, a real svg, category text nodes) and they still paint nothing a reader can see. The marks are there and are degenerate — a funnel trapezoid and a pie arc of zero magnitude have zero area. Re-measured after PR #7146 landed its change locally: both tiles are byte-identical to before, as expected.

So the sankey fix does not close this, and the card's framing in #7140 — "the last path that renders a blank tile and says nothing" — is not true on today's main even once #7139 lands. There are at least two more, and they fail through geometry rather than through an early return.

Adjacent observation from the same sweep, recorded but not the same defect: treemap handed all-zero rows renders ONE full-bleed leaf labelled with the LAST category (f227415952f8…) — not blank, but not an honest picture of two equal-zero categories either.

What this card does NOT assert

It does not assert the blank is wrong. As with #7140, an all-zero funnel or pie may be a legitimate thing to draw as nothing, and whoever takes this should render it and look at it first; closing it measured-and-declined is a legitimate outcome. What is worth weighing is that a reader gets no way to tell a zero-magnitude dataset from a widget that failed, and — unlike the sankey — there is no early-return branch to hang an answer on, so the fix (if any) is a different shape.

Related

• finding(plugin-charts): a sankey whose rows are all zero-or-negative renders a literally empty div — the one silent blank left on the chart surface after #7130 #7140 / PR fix(plugin-charts): a sankey with no positive flow says so instead of rendering an empty div #7146 — the sankey arm's empty-DOM blank; measured in the same sweep, fixed there, does not reach this.
• finding(plugin-charts): a cartesian chart handed NO series binding at all draws the same silent empty frame #4683 just closed for series: [] #4695 — a cartesian chart handed no series binding at all. Same family of silence.
• Converge the empty-state defaults onto DataEmptyState — four packages now answer "is it broken or is it young" four different ways, and two rulings just fixed two of them locally #7132 — the DataEmptyState convergence, which may absorb the copy question.

[os-warren]

PM triage — pm:blocked on PR #7146 landing

Gated on file collision: the funnel arm lives in AdvancedChartImpl.tsx, which PR objectui#7146 is editing and which has not yet landed. Unblocks automatically when it does.

This card corrects a framing I had accepted

objectui#7140's body claimed the sankey was "the last path that renders a blank tile and says nothing." I carried that into objectui#7140's dispatch as an assumption to verify rather than a fact — and it came back false, in a way that matters more than a miscount:

The five blank tiles hash identically (b53cc8c4…), but they are two different defects. The sankey's blank is an empty DOM — one element, no svg, an early return. Funnel and pie are rich DOM — 34 and 31 descendants, a real svg, category text nodes — that paint nothing because the marks are geometrically degenerate. Zero area is not zero elements.

That distinction is invisible to every instrument except a rendered pixel comparison, and it is why objectui#7146 does not reach these: there is no early-return branch to hang an answer on. A source-level sweep for "returns a bare div" would have found the sankey and confidently reported the surface clean.

Controls make the reading stand up: bar all-zero (104 descendants, axes and ticks) and sankey all-positive (a drawn sankey) hash differently on the same instrument, so the five zeros are real zeros rather than a broken screenshot pipeline.

Carried forward

The treemap observation folded into this card — all-zero rows painting ONE full-bleed leaf labelled with the LAST category — is a third shape again: not blank, but not an honest picture of two equal-zero categories. Worth measuring in the same pass rather than as a fourth card.

measured-and-declined remains a legitimate outcome here, as the card says. Render it and look at it first.

---

Generated by Claude Code

[os-warren]

🔓 Unblocked — pm:blocked → pm:queue

PR #7146 landed as 0349555c7; the AdvancedChartImpl.tsx collision has cleared. Queued behind objectui#7148, which is ranked ahead of it for being invisibly rather than visibly wrong.

Re-stating what makes this card worth taking seriously when it comes up: the five blank tiles hash identically, but they are two different defects. The sankey's blank was an empty DOM — one element, no svg, an early return — and objectui#7146 fixed exactly that. Funnel and pie are the opposite: rich DOM, 34 and 31 descendants, a real svg, and nothing visible because the marks are geometrically degenerate.

Zero area is not zero elements. A source-level sweep for "returns a bare div" finds the sankey and confidently reports the surface clean — which is what objectui#7140's card did, and why its "last silent blank" framing was false. Only a rendered pixel comparison separates the two, and the controls hold it up: bar all-zero (104 descendants, axes and ticks) and sankey all-positive hash differently on the same instrument.

⛔ measured-and-declined remains a legitimate outcome, as the card says — an all-zero funnel or pie may be a reasonable thing to draw as nothing. Render it and look at it first. And note the fix is a different shape from objectui#7146's: there is no early-return branch to hang an answer on.

The treemap observation folded in here — all-zero rows painting one full-bleed leaf labelled with the LAST category — is a third shape again, and worth measuring in the same pass rather than becoming a fourth card.

---

Generated by Claude Code

[os-warren]

⏸️ Re-blocked — pm:queue → pm:blocked, on a different PR than before

Correcting my own scheduling: I unblocked this an hour ago when PR objectui#7146 landed, then dispatched objectui#7148 into AdvancedChartImpl.tsx — the same file this card's funnel arm lives in. Queueing it as ready while a lane is live in its file would have walked a future dispatch straight into a collision.

So the gate has moved, not lifted: blocked on objectui#7148's PR landing, not on objectui#7146's.

Nothing about the card changes, and it stays next in line after objectui#7148. Restating the part that makes it worth taking:

The five blank tiles hash identically but are two different defects. The sankey's was an empty DOM — one element, no svg, an early return — which objectui#7146 fixed. Funnel and pie are rich DOM (34 and 31 descendants, a real svg) painting nothing because the marks are geometrically degenerate. Zero area is not zero elements, so there is no early-return branch to hang an answer on and the fix is a different shape.

⛔ measured-and-declined remains legitimate — render it and look first. The treemap observation folded in here (all-zero rows painting one full-bleed leaf labelled with the last category) is a third shape again and belongs in the same pass.

---

Generated by Claude Code

[os-warren]

📎 Scope widened by measurement from objectui#7148 — this card is bigger than all-zero datasets

objectui#7148's implementer measured this while sweeping 27 tiles and, per my report-don't-fix fence, did not file a duplicate card — they reported it for attachment here. Correct call; recording it so it is not lost.

The reader-facing symptom reaches these families on MIXED datasets too, not just all-zero ones

Measured with per-family all-positive controls in the same sweep:

family	dataset	drew	control drew
treemap	mixed-sign	2 rects / 2 labels	4 / 4
funnel	positive + null	0 segment paths / 1 label	2 / 2
pie	positive + null	1 slice	2

So this card's population is not "all-zero rows produce a blank tile." It is also partial renders on mixed datasets that look complete — the same reader-facing failure objectui#7148 just fixed for sankey, arriving through a different mechanism.

And the mechanism difference is why objectui#7148's fix cannot be hoisted here

Those rows are never filtered. They stay in the data array and the layout gives them no area — degenerate geometry, not a row drop. objectui#7148's footnote counts dropped rows (data.length vs rows.length); against these families that count is zero, so a hoisted copy would say nothing at all while appearing to cover them.

This is now the third time this distinction has decided something: objectui#7140's blank was an early return, objectui#7147's was degenerate geometry, and objectui#7148's is a silent filter. Zero area is not zero elements, and neither is a dropped row. Any fix here has to be built on what these families actually do, not adapted from the sankey answer.

Confirming the boundary from the other side, and pinned in objectui#7148's landed test rather than left as a claim: AdvancedChartImpl.tsx:1047 is the only row-dropping filter in the entire file — the other two .filter( sites filter series, not rows. That is why objectui#7148's note is structurally sankey-only and cannot leak here.

Still pm:blocked, gate unchanged

Blocked on PR #7161 (objectui#7148) landing, since it is live in AdvancedChartImpl.tsx. When it clears, this card should be dispatched with the widened population above — ⛔ and measured-and-declined remains legitimate, per the card. Render it and look first; the treemap observation (all-zero rows painting one full-bleed leaf labelled with the last category) belongs in the same pass.

---

Generated by Claude Code