Files
pulse/tests/integration/scripts/bootstrap-timing.md
T
pulse-triage[bot] 6667bd8ad0 test: capture bounded paired Settings bootstrap timings
The hosted Settings failure stalls during bootstrap without enough evidence to separate server delay from browser scheduling. Attach redacted, bounded cookie-session HTTP timings alongside browser response timings without weakening readiness or layout assertions.

Change-source: pulse-maintainer
2026-09-09 10:03:05 +01:00

24 lines
1.5 KiB
Markdown

# Settings bootstrap timing diagnostic
The desktop-to-390px Settings test attaches `bootstrap-paired-timing` to its
Playwright report, including on assertion failure. It issues at most one extra
GET each for summary and runtime capabilities, when the browser first requests
that path. The HTTP client shares the test's cookie session but not the browser's
network scheduler. Redirect following is disabled; each probe has a five-second
limit. No readiness condition, capability requirement or assertion is relaxed.
`started` is host epoch milliseconds. Browser duration ends at response headers;
HTTP duration includes response receipt. Null browser status/duration is censored,
not a server error. Null HTTP status is a transport failure/timeout without a
received response; the exception is deliberately not retained. Reports exclude
headers, credentials, query strings and payloads.
For the next hosted observation, retain this attachment, the browser trace and
application startup timestamps from the same job/source. Compare overlapping
summary/capabilities requests; a quick HTTP response with stalled browser narrows
the question towards browser scheduling, while both delayed supports further
server/startup measurement. Neither proves a particular lock is responsible.
Extra probes can warm caches or contend themselves, so do not claim a controlled
effect size or historical causality. Do not select favourable repeats, widen the
assertion timeout, or treat a successful diagnostic as probation promotion.