Live, fail-closed experiment

Run the proof in this browser

Choose React 18 or React 19. The suite loads exact Apollo and React versions, discards warmups, and runs 96 measured samples in mirrored order. Millisecond values depend on this browser; commit counts and validation checks are the primary result.

Benchmark controls

The 400-row default gives each React commit substantial real DOM work without adding a synthetic delay.

React runtime Balanced blocks Subscriber counts DOM rows per subscriber

A balanced block runs the three arms forward and backward (ABCCBA or CBAABC). One subscriber is the negative control; larger counts test amplification. These settings carry across a React runtime reload.

Exact runtime: Apollo Client 3.6.9 and 3.14.1, the selected React release, and the matching react-dom/profiling release are imported from esm.sh. Changing React runtime reloads the page so packages from different React releases cannot mix. An unavailable or mismatched package fails the run instead of silently changing the environment.

Ready. The first run downloads exact package versions from esm.sh.

Measured output

Numbers first

The three large values show mean React commits at the largest subscriber count in this run. The table keeps every tested count visible.

Largest subscriber count in this runpopulated after Run proof

Apollo 3.6.9
unchanged package — mean React commits

Apollo 3.14.1
unchanged package — mean React commits

Apollo 3.14.1
grouped-delivery diagnostic — mean React commits

Swipe horizontally to see every column →

Commit, render, and completion measurements
Subscribers	Experiment arm	Valid samples	React commits, mean (min–max)	Subscriber renders, mean	Final commit p50	Final paint p50
Run the benchmark to populate live results.

p50 is the median measured sample. Final paint includes two animation frames and often reflects display cadence; treat it as a completion boundary, not package-only CPU time.

Advanced scheduling and rendering counters

A host task is one browser event-loop turn. A logical notification is one Apollo result publication to one observer. A delivery batch is the group of observer callbacks drained together by the diagnostic arm. p90 is the value at or below which 90% of samples fall.

Advanced instrumentation
Subscribers	Experiment arm	Host tasks	Logical notifications	Delivery batches	Largest batch	Derived layout effects	React CPU mean	Geometry-read mean	Final commit p90	Final paint p90
Run the benchmark to populate live results.

Proof verdict

Run the benchmark. A result passes only if every required condition holds.

The checks cover exact package versions, identical final data, notification and observer-delivery counts, task and microtask order, no dropped values, and the expected commit progression.

Commit-by-commit illustration

Watch one result spread across the screen.

Each box is one measured React commit. A snapshot such as 11110000 means four of eight query consumers show the new value while four still show the old value.

Q — query-result commit

One or more useQuery consumers publish the new Apollo cache value to the UI.

D — derived parent-state commit

After Q, the fixture's useLayoutEffect reads DOM geometry and updates shared parent state. D models downstream React work; it is not another Apollo result.

Before a run, the strips illustrate the expected eight-subscriber pattern. Run proof replaces them with a measured trace from this browser.

Apollo 3.6.9 stock2 commits

Q · all 8D · combined

Visible query progression: 00000000 → 11111111

Apollo 3.14.1 stock16 commits

Q1D1Q2D2Q3D3Q4D4Q5D5Q6D6Q7D7Q8D8

Visible query progression: 00000000 → 10000000 → 11000000 → … → 11111111

Apollo 3.14.1 + grouped-delivery diagnostic2 commits

Q · all 8D · combined

Visible query progression: 00000000 → 11111111

Commit-by-commit snapshots

Representative sample at the largest subscriber count
Experiment arm	Commit	Snapshot after render	Derived version	Elapsed ms
Run the benchmark to populate the trace.

Raw, reviewable JSON from this run

Run the benchmark to generate JSON.

Pinned source evidence

The code paths explain the measured task timeline.

Both versions schedule one separate zero-delay browser task per watched ObservableQuery. After each result reaches React, the versions request different update priorities.

Apollo 3.6.9

Ordinary local state update

observer result
  → setTick(tick => tick + 1)
  → requestUpdateLane(...)

Outside a browser event, React assigns ordinary DefaultLane priority.
Compatible pending work can coalesce before React commits.

Apollo 3.14.1

External-store consistency update

observer result
  → handleStoreChange()
  → forceStoreRerender(..., SyncLane)

External store means state owned outside React—in this case, Apollo's query store.

React's forceStoreRerender assigns synchronous SyncLane priority.
A React microtask can commit before Apollo's next separate delivery task.

Evidence boundary

The live timeline verifies separate host tasks, observer callbacks, microtasks, and commits. The lane names are the source-traced explanation for these pinned versions, not a separately manipulated benchmark variable. Apollo PR #11083 introduced the external-store callback to fix update ordering, so restoring the old setter is not a safe fix proposal.