test(e2e): isolate awaited Person route stages in Graph return (#740)

FO
3h ago
+238-14

Purpose

Continue E2E performance tracker #740 after merging #767. Real Chromium Graph profile #39165518995 attributed an intermittent Person return delay to the wait for offline banner DOM insertion: 1.041/1.132/0.026s versus 0.020–0.025s for other entity routes. That does not identify the awaited operation causing it.

Change

Changes are limited to the existing test_record_graph_navigation_both_directions E2E test and the existing manual-only profiling workflow:

  • When the canonical PRKS_E2E_PROFILE predicate is true and only during the Person Graph → detail return, install temporary in-page wrappers around the production classic-script global functions for prksRenderTabRoute and prksCommitTabRouteRender (inclusive envelopes), the durable queue read, guarded detail fetch, effective Person projection, pending metadata hydration, Person rendering and banner insertion; where defined, wrap individual pending-metadata refreshes too.
  • Preserve argument binding, returned values and rejections; record performance.now()-based elapsed timings in the browser so Playwright IPC time is not wrongly attributed to an awaited function.
  • After all existing real-Chromium actions and offline-banner assertions pass, await both route-envelope sample completions, restore original functions even on assertion failures, and report graph_nav_person_route_*_{sum,max} through the existing opt-in recorder. The manual workflow requires all eight core stages, both aggregates, in every measured trial. A 1µs floor preserves valid zero-duration samples in the existing profiler.
  • An ordered timing trace and per-stage call count, maximum, total inclusive duration and AbortError count are printed in the run log. Expected superseded-route AbortError rejections remain observed but do not fail the test; non-abort failures still do. These functions may be nested or overlap. Inclusive measurements must not be added together.

No production application files, assertions, service-worker logic, CI trigger policy, or standard nonprofiled E2E behavior change. All browser profiling is optional and temporary.

Verification / follow-up

  • Final documentation-only head a693acc: all required CI and latest code review green. The tested implementation head fdf071c passed all seven workflows (Full E2E, PRKS Test Gate, CodeQL, Fast Static, workflow lint, zizmor, Dependency Review), with no unresolved review threads and Codex no findings.
  • Manual Graph profile #39199744078 on exact implementation head fdf071c: one excluded warm-up and three passing serial Chromium trials.
  • All eight required graph_nav_person_route_*_{sum,max} phase pairs present in each run. Chronological trace confirms exactly one route commit/detail fetch, two durable queue reads, zero aborts, and no overlapping Person route commit on all three runs.
  • Attribution: Person prksOfflineDetailFetch took 928.1, 851.7, 1054.3ms (median 928.1ms), accounting for nearly all the route commit (958.0, 881.0, 1085.9ms). Metadata hydration median 2.4ms, render 5.8ms, and DOM banner insertion 2.1ms. See docs/e2e-performance.md. These are browser-side inclusive phases, not additive.
  • Next separate diagnostic: distinguish why prksOfflineReadEntity is slow: initial connectivity state, cache eligibility / cache read, result source, read-through fallback and actual network attempts. Preserve domain/generation fencing; do not infer a safe production fix or speedup from the current profile.
  • Maintainer explicitly authorizes merge.

This PR is instrumentation only. Do not merge without further maintainer approval.

Summary by cubic

Extends the opt-in Person Graph return profiler (#740) with real Chromium measurements that now attribute the intermittent return delay to the awaited prksOfflineDetailFetch stage. Instrumentation only; not for merge without maintainer approval.

  • Wraps eight required classic-script stages plus optional per-metadata refreshes, recording browser monotonic timings with overlap, call counts, and abort outcomes; restores originals even on assertion failures.
  • The manual workflow now requires all eight stages' sum and max aggregates so a partial profile cannot pass.

Finding

  • Three serial Chromium trials show prksOfflineDetailFetch accounts for most of the return wait (~0.93s inclusive median of ~0.96s total); durable reads, metadata hydration, rendering, and banner insertion are each single-digit milliseconds.
  • The run does not distinguish prksOfflineReadEntity internal branches (coherent cache snapshot vs read-through fallback); the next diagnostic should capture connectivity state and the returned source.