Vue-node text anti-aliasing makes @screenshot specs nondeterministic, ejecting PRs from the merge queue

[christian-byrne]

What

@screenshot e2e assertions that frame a Vue node containing a text widget are exposed to a text-rasterization nondeterminism that is not specific to any one spec. It has already ejected unrelated PRs from the merge queue.

Evidence

Traced while fixing one instance in #15356 (pan.spec.ts → @mobile Can pan with touch):

• The failure is always 40 pixels (ratio 0.01 of all image pixels) are different, and the actual/diff PNGs are byte-identical across different CI runners.
• Every pixel outside the ckpt_name widget's value text is identical between passing and failing runs, including the node's own transform and border. The diff is anti-aliasing inside the glyphs of a truncated value — identical glyph positions (per-glyph centroid drift < 0.09px), roughly 5% less ink.
• Playwright already captures a stable screenshot and re-fails all three retries with the same 40 pixels, so no readiness signal can wait it out.

Why this is not one test's problem

Nothing in that mechanism is specific to panning. The conditions are: a text widget whose value is truncated, inside a filtered and contain-ed node subtree, captured by an exact-match screenshot. Those conditions hold in every @screenshot test that frames a Vue node with a text widget.

Impact

Not just red PR checks — silent merge-queue ejection of already-approved changes. Three queue branches on 2026-08-17 on the same base 926d78c8bf: pr-14068 and pr-15067 both failed with the identical 40 pixels (neither can move a canvas), while pr-15108 passed on the same base.

Suggested direction

Decide this once, centrally, rather than per spec as each one starts flaking:

• a default maxDiffPixels for @screenshot assertions that frame node text, sized well below a real regression (a 1px pan error moves 3615 px; an observed genuine rendering change moved 3146), or
• masking the widget value text where the assertion is about geometry rather than text, or
• pinning whatever in the font/rasterization stack is varying, if it can be identified.

15356 bounds the single known instance; this issue is for the shared cause.

[coderabbitai]

🔗 Related PRs

#14682 - ci: bump comfyui-ci-container to 0.0.22 [open]
#15059 - test: ledger the WAS vue-height flip and the MathExpression sweep crash [merged]
#15092 - fix(layout): keep a node layout ref alive until its last holder releases [open]
#15327 - test: add ECS migration regression coverage [open]
#15356 - test: stop mobile touch-pan screenshot flaking on text anti-aliasing [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[christian-byrne]

Amending this issue's premise — a bisect landed after I filed it, and it points at a cause I did not consider.

I framed this as browser/font-level anti-aliasing entropy exposing every @screenshot spec that frames node text. The entropy framing no longer explains the data: mobile-chrome is red on main itself and flips green→red at 16a8790b2 ("fix: missing-media follow-ups from #14578 review", #14668), with e357fb96d and everything before it green.

That fits the pixel signature better than entropy does. The 40 pixels are inside the ckpt_name widget's value text at identical glyph positions with about 5% less ink, and #14668 changes missing-media scanning and error-clearing. A styling change on a value whose model file is absent on the CI backend gives exactly same-glyphs/different-ink.

Two consequences:

1. The single-test fix in test: stop mobile touch-pan screenshot flaking on text anti-aliasing #15356 may be masking a genuine rendering change rather than bounding noise. I have asked for that to be resolved there before it merges — regenerate the baseline if the new rendering is intended, or fix it in fix: missing-media follow-ups from #14578 review #14668 if it is not.
2. This issue's systemic claim is weakened but not void. The exposure is real — an exact-match screenshot over truncated node text will trip on any styling change to that text, intended or not — but the trigger observed so far is a product change, not runner entropy. That argues for deciding what these assertions are for (geometry vs. appearance) and masking or bounding accordingly, rather than for chasing a rasterization variable that may not exist.

Leaving this open on the narrower, still-true point: @screenshot specs that frame node text have no policy, so each one becomes someone's incident when the text beneath it changes. The merge-queue ejection evidence stands either way.

[christian-byrne]

Second amendment — my previous one was based on a bisect that has since been disproven, and the original premise of this issue turns out to be closer to right than my retraction of it.

I amended this issue to say the trigger was a product change from #14668 rather than rendering nondeterminism. @jaeone94 refuted that on #15356 with evidence I could not argue with:

• Merge-queue batches without fix: missing-media follow-ups from #14578 review #14668 failed this test, and fix: missing-media follow-ups from #14578 review #14668's own batch passed — the opposite of a deterministic flip.
• The first red on main predates fix: missing-media follow-ups from #14578 review #14668 by 21+ hours, on refactor: use the coins icon for credits everywhere #15089's own merge commit (the commit that refreshed this baseline).
• The failing frames match the pre-refactor: use the coins icon for credits everywhere #15089 baseline captured 7/29 with a 0-pixel diff, and passing frames match the current baseline with a 0-pixel diff — two discrete variants, both older than fix: missing-media follow-ups from #14578 review #14668. Container digest and runner image are identical between passing and failing runs.

So the "~5% less ink" is July's baseline variant, not new styling. Withdraw the #14668 attribution entirely.

Sharpened problem statement. This is not smooth anti-aliasing jitter and not a product regression. The renderer produces one of two discrete, byte-stable variants of the same text, in an identical container and runner image. A baseline regen captures whichever variant it happens to see, so the test is quiet until the other variant next appears. That history is visible: 6 failures Jun 13–29, then 46 failure-free days after the Jul 2 full regen, then this wave from Aug 16 06:01.

That reframes the fix. Regenerating the baseline is not a fix, it is a coin flip that buys a quiet period. Neither is a tolerance, which is what merged in #15356 — it bounds the symptom while both variants remain reachable. The fix is to make the rasterization deterministic (pin the font stack / AA settings the two variants differ on) or to stop asserting on that text where the assertion is about geometry.

Still open, and now with a concrete target: find what selects between the two variants.