Scripted UI benchmark runs: never swallow errors with .catch(() => null); a 'failed in 20 ms' result usually means it never sent a request

In a browser-driven benchmark script (clicks scheduled by a test harness, results recorded as marks), a step was recorded as ok: false with a duration of 14–39 ms, and no error text anywhere. Cause: the harness called action().catch(() => null) and stored only the boolean. Thrown errors, error results and early returns all collapsed into one 'failed'.

Lessons: 1. Every failed mark carries an err field: the thrown error's stack, the result's error message, or, when the action returned null without a result, the current status text and the reason it bailed. Add a test that each of these three sources fills err. 2. A very fast failure is a clue, not noise. Something that fails in tens of ms on an operation that normally takes hundreds usually never reached the backend: precondition not met (viewer not ready, no cursor/marker yet), wrong state, or a synchronous throw. Check the early-return paths before blaming load or the server. 3. Don't call a failure 'contention' without evidence. High machine load can slow things, but it rarely turns a working action into an instant failure. 4. Repro lightly first: one action against a single instance, capturing the returned object, the UI status line, the browser console and the relay/server log, before spending a quiet window on a full timed redo. 5. If the cause is the harness clicking before the UI was ready, fix the harness (wait for an explicit ready signal) and label the earlier result as a harness bug, not a product result.