Two tile-widen e2e specs are stale against the grafana-grid@2 placement shape

[BorisTyshkevich]

What

Two tile-open-workbench e2e specs fail deterministically on all three engines (chromium, firefox, webkit) on main. Tile widen no longer increases a grid tile's rendered height, and for a narrow tile the placement entry never appears at all.

1) tests/e2e/tile-open-workbench.spec.js:349
   › widen doubles a grid tile's rendered width and height, then wraps
   expect(wide.height).toBeGreaterThan(before.height)
   Expected: > 208
   Received:   208            ← width grows (line 348 passes); height does not

2) tests/e2e/tile-open-workbench.spec.js:398
   › a narrow tile drops the inline widen but keeps its menu row
   await expect.poll(() => …items?.['t-sales']?.span ?? null).toBe(2)
   Expected: 2
   Received: null             ← Timeout 5000ms; the placement entry is absent

Line 350–351 asserts the persisted placement should be { span: 12, height: 4 }, so both the rendered geometry and the stored height are in question.

Evidence — CI, both engines-wide and reproducible

commit	run	result
8decf2b (main, current)	30474498800	6 failed, 568 passed
f68861c (merge of #549, pre-dates today's work)	30475331599	6 failed, 556 passed

6 = the same 2 specs × 3 engines in both runs. Deterministic, not flake.

Not caused by today's batch

f68861c is the merge of PR #549 and is the commit main sat at before today's bug/low batch (#554–#558, #561–#563). It already fails identically, so none of those PRs introduced this. That also matches three independent local reproductions on pre-batch bases during that work.

This points at the grafana-grid@2 style-sizing track — #535 / #538 / #549 — or something earlier. The exact culprit is not yet pinned. Narrowing it is cheap and mechanical: push a temp branch at a candidate commit and gh workflow run ci.yml --ref <branch>, since workflow_dispatch is one of the few events that actually runs the e2e job (see #564). I stopped at "not from today's batch" rather than guessing a specific PR.

Why this went unnoticed

The e2e job never runs on pull requests or on pushes to main — it is gated to tags, schedule and manual dispatch — while the overall check still reports success. That is filed as #564; this issue is the concrete regression that gap let through.

Acceptance

• Both specs pass on chromium, firefox and webkit.
• Whatever the fix, it restores the behaviour the specs describe (widen grows height and persists { span: 12, height: 4 }; a narrow tile still records span: 2) rather than relaxing the assertions to match current output — the specs encode Dashboard panel header: duplicate, widen and expand actions #535's intended widen semantics.
• Identify the originating change so the fix can say what it restores.

[BorisTyshkevich]

Quarantined, not silenced — PR #566 (which closes #564) turns the Playwright suite on for pull requests, and a new gate cannot be switched on against a red baseline without blocking every PR. So both specs are marked test.fail() in tests/e2e/tile-open-workbench.spec.js.

Deliberately not test.skip / test.fixme. Those stop exercising the code path entirely, and nobody would notice when this is fixed. test.fail() keeps both specs running, so the moment the underlying defect is repaired they report:

Expected to fail, but passed.

which is the signal that removing the two test.fail() lines is part of the fix for this issue.

Two things the fix must not do:

• do not relax the assertions to match current output — they encode Dashboard panel header: duplicate, widen and expand actions #535's intended widen semantics (wide.height > before.height, and a persisted { span: 12, height: 4 } / span: 2);
• do not convert the quarantine to skip/fixme.

Attribution so far: identical 6 failures (2 specs × 3 engines) at 8decf2b and at f68861c, so this pre-dates the #554–#563 batch and points at the grafana-grid@2 sizing track (#535/#538/#549) or earlier. The exact culprit is still unpinned; narrowing it is mechanical now that workflow_dispatch runs the suite — push a temp branch at a candidate commit and gh workflow run ci.yml --ref <branch>.

[BorisTyshkevich]

Correction — I filed this as a product bug and it is not one. Retitled accordingly; PR #567 fixes the specs.

The original framing ("widen no longer grows a grid tile's height") assumed the assertion was right and the code wrong. Measuring the real behaviour shows the opposite:

initial   h=208px w= 867px   t-sales={"grid":{"span":8}}
press 1   h=208px w=1305px   t-sales={"grid":{"span":12,"height":2}}
press 2   h=208px w= 101px   t-sales={"grid":{"span":1,"height":2}}

Span doubles 8 → 12 and wraps to 1; the height never moves. src/dashboard/application/panel-widen.ts specifies exactly that, three times over — the module does "never anything two-dimensional" (the corner drag, #291, owns free-form resize), grid keeps "height ... always resent unchanged", and nextPanelPlacement states "Height is preserved". t-sales authors no height, so it resolves to DEFAULT_GRID_HEIGHT_UNITS (2) → 32 + 88*2 = 208px, before and after. The assertion demanded > 208 and got exactly 208.

So there is nothing to fix in src/. What is stale is the grafana-grid@2 style-keyed placement shape leaking into two specs written against the flat v1 shape:

• expect(wide.height).toBeGreaterThan(before.height) demanded the one thing widen must not do → now asserts height is unchanged, which pins the documented contract more tightly than the old assertion did;
• toEqual({ span: 12, height: 4 }) → { grid: { span: 12, height: 2 } };
• items['t-sales']?.span → items['t-sales']?.grid?.span. The ?? null fallback is what turned a shape mismatch into an opaque 5s timeout instead of a legible failure. Its expected value (2) was always correct — the two presses wrap span to 1 and the ⋯ row clicked next steps it to 2.

The test.fail() quarantine added in #566 is removed; both specs pass on their own merits (chromium 21, webkit 20).

Two things worth keeping from this:

1. The style change should have updated these specs in the same commit. It did not, and nothing failed, because the browser suite never ran on a PR until Playwright e2e never runs on PRs or main — green CI does not mean the browser suite passed #564 — this is the first defect that gate caught.
2. A ?? null inside a poll converts "wrong shape" into "timed out", which cost real diagnosis time here. Worth avoiding in new e2e polls.

Thanks to @btyshkevich for pushing back on the "widening should change width, not height" premise — that is what prompted re-reading the spec instead of trusting the red test.