Get current Luxar state
Now includes safety check for debug interface availability
Deadline-bounded (#1651), like getConsoleMessages. This is the most
called probe in the suite — well over a hundred call sites, in most spec
files. Together with getConsoleMessages it is what the bulk of the specs
depend on, and both are now bounded; the rest of this
file's bare page.evaluate calls (renderOnce, getWebGLErrors,
focusCanvas, captureCanvasRGBA, probeWebGPUBackend, …) are not. Before
the bound, a starved page reported the stall as a bare
Test timeout of 120000ms exceeded pointing at the page.evaluate line
below, with nothing to say which dataset or which probe was pending.
Measured on performance_benchmark_example.luxar.zarr (100 nodes, 100k
points): getState() costs 0.5 ms in-page and returns 12 KB, yet the round
trip took 111,003 ms in one run and >150,000 ms in another, because the
viewer's frame loop saturated the main thread and starved Playwright's
Runtime.callFunctionOn. That underlying viewer bug (#1724) is fixed — the
loop now paces itself — but the bound stays: it is the generic diagnostic
for a starved page, not a workaround for one scene.
The same honest caveat as getConsoleMessages applies: a deadline cannot
tell a page that will never answer from one that would have answered late,
so any value here can cut short a stall that would have ended. 45 s matches
getConsoleMessages for the reasons documented there.
THROWS rather than returning a fallback. Callers overwhelmingly assert on
the result (expect(state.totalPoints).toBeGreaterThan(0)), so any stand-in
value would either fail with a nonsense diagnostic or — worse, for the
state && … and !state.isLoading polling helpers above — read as a pass.
Parameters
page: Page
Playwright page
timeout: number = 45000
Deadline for the in-page probe, in ms
Returns Promise<any>
Throws
If the page does not answer the probe within timeout ms
Get current Luxar state Now includes safety check for debug interface availability
Deadline-bounded (#1651), like getConsoleMessages. This is the most called probe in the suite — well over a hundred call sites, in most spec files. Together with
getConsoleMessagesit is what the bulk of the specs depend on, and both are now bounded; the rest of this file's barepage.evaluatecalls (renderOnce,getWebGLErrors,focusCanvas,captureCanvasRGBA,probeWebGPUBackend, …) are not. Before the bound, a starved page reported the stall as a bareTest timeout of 120000ms exceededpointing at thepage.evaluateline below, with nothing to say which dataset or which probe was pending. Measured onperformance_benchmark_example.luxar.zarr(100 nodes, 100k points):getState()costs 0.5 ms in-page and returns 12 KB, yet the round trip took 111,003 ms in one run and >150,000 ms in another, because the viewer's frame loop saturated the main thread and starved Playwright'sRuntime.callFunctionOn. That underlying viewer bug (#1724) is fixed — the loop now paces itself — but the bound stays: it is the generic diagnostic for a starved page, not a workaround for one scene.The same honest caveat as
getConsoleMessagesapplies: a deadline cannot tell a page that will never answer from one that would have answered late, so any value here can cut short a stall that would have ended. 45 s matchesgetConsoleMessagesfor the reasons documented there.THROWS rather than returning a fallback. Callers overwhelmingly assert on the result (
expect(state.totalPoints).toBeGreaterThan(0)), so any stand-in value would either fail with a nonsense diagnostic or — worse, for thestate && …and!state.isLoadingpolling helpers above — read as a pass.