Creating and closing a page per unit of work makes page.evaluate fail intermittently:
Runtime.evaluate -32000 Promise was collected
Reusing a single page and navigating it makes the failure go away completely.
Same setup as #2744, but filing separately since that one is about missing APIs and this is a bug.
Reproduction
A plain loop over ~10 URLs at 2 viewport widths, 20 page-visits per run:
context.newPage() → setViewportSize → goto → waitForSelector → a few synchronous evaluate calls → page.close()
Same script, same URLs, idle machine, 40 page-visits per mode:
| Mode |
Failures |
| new page per URL, closed after each |
9 of 40 (6, then 3) |
one page reused, goto per URL |
0 of 40 |
| Playwright doing identical work |
0 of 60 |
The rate isn't stable — the same pattern in a real script showed 5-10% rather than 20% — so it looks timing sensitive.
Why it bit us harder than the rate suggests
Our script measures rendered typography across a few hundred page-visits and reports what it found. A failure isn't a crash, it's a page that silently goes unmeasured, and the summary still prints a confident total. We lost about a tenth of the run while the reported numbers barely moved.
That's on us to handle, and we now count and report unmeasured units separately. But it's worth flagging that this failure mode is quiet by nature.
What we ruled out
document.fonts.ready and long-awaited promises inside evaluate (rewrote the whole thing as synchronous evaluates driven fro
Creating and closing a page per unit of work makes
page.evaluatefail intermittently:Reusing a single page and navigating it makes the failure go away completely.
Same setup as #2744, but filing separately since that one is about missing APIs and this is a bug.
Reproduction
A plain loop over ~10 URLs at 2 viewport widths, 20 page-visits per run:
context.newPage()→setViewportSize→goto→waitForSelector→ a few synchronousevaluatecalls →page.close()Same script, same URLs, idle machine, 40 page-visits per mode:
gotoper URLThe rate isn't stable — the same pattern in a real script showed 5-10% rather than 20% — so it looks timing sensitive.
Why it bit us harder than the rate suggests
Our script measures rendered typography across a few hundred page-visits and reports what it found. A failure isn't a crash, it's a page that silently goes unmeasured, and the summary still prints a confident total. We lost about a tenth of the run while the reported numbers barely moved.
That's on us to handle, and we now count and report unmeasured units separately. But it's worth flagging that this failure mode is quiet by nature.
What we ruled out
document.fonts.readyand long-awaited promises insideevaluate(rewrote the whole thing as synchronous evaluates driven fro