Filed unassigned by the implementer of #7140 (PR #7146). ⛔ Out of scope there: that card's trigger is links.length === 0 — no row survives the filter — and PR #7146 answers exactly that branch. This is the branch next door, where some rows survive, and it is arguably the worse of the two.
The measurement
packages/plugin-charts/src/AdvancedChartImpl.tsx, the sankey arm, at origin/maine8e4c4d:
const rows = data.filter((r) => (Number(r?.[dataKey]) || 0) > 0);
const nodes = [{ name: rootName }, ...rows.map(...)];
const links = rows.map(...);
The filter is unconditional. A sankey handed
[{ stage: 'New business', amount: 40 },
{ stage: 'Refunds', amount: -25 },
{ stage: 'Chargebacks', amount: -12 }]
draws one flow — "New business" — and nothing anywhere says the other two rows existed. Measured in Chromium in the same sweep: the one-positive-among-zeros tile rendered svg: 1, path: 3, 18 descendants, and no diagnostic of any kind. It is a normal, healthy-looking, confident sankey of a dataset it is showing a third of.
Why it is worth recording separately
#7140's blank is at least visibly wrong — nothing is on screen, and after PR #7146 it says so. This one is invisibly wrong: the chart looks correct, so nobody re-reads the dataset. A pipeline chart that quietly omits every refund/credit/chargeback row is a business-wrong picture presented as a complete one, and the same reasoning behind the empty-state work applies with more force, not less: the reader cannot tell a partial flow from a whole one.
Note the filter is also what folds null and unparseable measures to 0 (Number(...) || 0), so those rows disappear the same way in a mixed dataset.
What this card does NOT assert
It does not assert the drop is wrong. A flow has no negative width, so a sankey genuinely cannot draw those rows; discarding them may be the only thing it can do. What is undecided is whether it must say it did — and if so, whether that is a footnote beside a drawn chart, a count of omitted rows, or a refusal. That is a judgement this card does not pre-make, and it needs a look at a real dataset before anyone writes code. Note also that PR #7146 pins the "one positive among zeros still draws" boundary, so any answer here must keep a drawable sankey drawable.
Related
Filed unassigned by the implementer of #7140 (PR #7146). ⛔ Out of scope there: that card's trigger is
links.length === 0— no row survives the filter — and PR #7146 answers exactly that branch. This is the branch next door, where some rows survive, and it is arguably the worse of the two.The measurement
packages/plugin-charts/src/AdvancedChartImpl.tsx, the sankey arm, atorigin/maine8e4c4d:The filter is unconditional. A sankey handed
draws one flow — "New business" — and nothing anywhere says the other two rows existed. Measured in Chromium in the same sweep: the one-positive-among-zeros tile rendered
svg: 1,path: 3, 18 descendants, and no diagnostic of any kind. It is a normal, healthy-looking, confident sankey of a dataset it is showing a third of.Why it is worth recording separately
#7140's blank is at least visibly wrong — nothing is on screen, and after PR #7146 it says so. This one is invisibly wrong: the chart looks correct, so nobody re-reads the dataset. A pipeline chart that quietly omits every refund/credit/chargeback row is a business-wrong picture presented as a complete one, and the same reasoning behind the empty-state work applies with more force, not less: the reader cannot tell a partial flow from a whole one.
Note the filter is also what folds
nulland unparseable measures to0(Number(...) || 0), so those rows disappear the same way in a mixed dataset.What this card does NOT assert
It does not assert the drop is wrong. A flow has no negative width, so a sankey genuinely cannot draw those rows; discarding them may be the only thing it can do. What is undecided is whether it must say it did — and if so, whether that is a footnote beside a drawn chart, a count of omitted rows, or a refusal. That is a judgement this card does not pre-make, and it needs a look at a real dataset before anyone writes code. Note also that PR #7146 pins the "one positive among zeros still draws" boundary, so any answer here must keep a drawable sankey drawable.
Related