[rmcdaniel]

Review class: R0 (CI wall time; same checks, same failure semantics).

Why

The Shared Server fixtures cycle takes about 36 minutes, and the corpus part is its long pole: 25 to 31 minutes on each database (run 40136659746). PR delivery is outpacing CI, so CI comes first.

On that run's postgres-storage (postgres-17, corpus), the comparison step took 26.8 minutes:

Phase	Minutes
Records (published PHP, embedded, native)	~6
Patch and legacy-marker profiles	~1.5
Range repair (two runs)	1.3
Published-SDK direction lanes	12.7
Killed-node recovery and takeover refusal	~5

Lane times, from each profile's compare container:

Lane	Profiles	Minutes
1	updates, update failures, child directions	10.3
2	signals, namespace signals, selected-run signals	12.7
3	timers, activity directions, queries	6.7

What

• A fourth matrix part, sdk-directions, in mysql-execution, postgres-storage and execution-and-codec, runs sdk-direction-lanes.sh against a native node started on the part's bootstrapped database.
  • The lanes depend on nothing the corpus records leave behind. Each profile brings its own published PHP and embedded databases and its own workflow-ID prefix, and needs only a native node.
  • Every profile still runs once per database.
• The corpus step keeps its records, profiles, range repair and restart cases, and no longer runs the lanes.
• Each lane group header now records the profile's duration (sdk-updates (exit 0, 276 s)), so lane balance can be measured from the job log.
• The aggregate result reads each job's combined matrix result, so it covers the new part unchanged.

Evidence

• ServerParityPartsTest now requires four parts, and the lanes in exactly one step, in sdk-directions.
• ServerParitySdkDirectionLanesTest checks the duration in each group header.
• Results:
  • With ServerParityAggregateTest and MergeGroupTriggersTest: 52/52 pass (node 18, git 2.43).
  • The Docker isolation policy passes.
  • The public boundary check passes.
  • actionlint 1.7.7 reports nothing new beyond three more SC2034 notes, from the new readiness loops that repeat the existing for attempt in … pattern.
• Expected:
  • corpus drops by about 12 minutes on each database.
  • cohorts (20 to 23 minutes) becomes the long pole, for a cycle of about 28 minutes.
  • Six more jobs per cycle, each about 16 minutes.
  • This PR's own run is the first measurement; I'll post before and after timings here.

🤖 Generated with Claude Code

[rmcdaniel]

Measured on this PR's own run, at exact head 5287ee95b.

	Before: run 40136659746 (#745, attempt 1)	After: run 40148128623 (this PR, attempt 1)
Cycle wall time (first job start to last job end)	36.0 min	27.1 min (−25%)
Longest corpus job	30.9 min	17.7 min
Runner minutes	395	401 (+1.5%)
Jobs	28	34

• New long pole: the cohorts parts, 18 to 22 minutes. The new sdk-directions parts finish in 15.5 to 16 minutes.
• Lane balance, from the new group headers on mysql-execution (mariadb-10.11, sdk-directions):
  • updates, update failures, child directions: 190 + 178 + 66 s = 7.2 min;
  • signals, namespace signals, selected-run signals: 102 + 276 + 146 s = 8.7 min;
  • timers, activity directions, queries: 101 + 75 + 139 s = 5.25 min.
• One flake: in attempt 1, sdk-queries on that same MariaDB job recorded query-sdk-python-rust with HTTP status 0 (a transport failure, not a different answer) against native. The other five databases' sdk-queries passed in the same run. Rerunning only that job (attempt 2) passed, and every check is now green.
• Next: the cohorts part is next in line. Its slowest cohort, corrected markers, takes 8.8 minutes and could run as its own part. That's a separate change, after measuring this one on main.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rmcdaniel]

General bounded CI review of exact head acafcea: no finding in the four-file workflow/lane-wrapper change. This is a wrapper review, not native/fixture/R2 acceptance.

• Confirmed the same nine SDK profiles are invoked exactly once in each of the six existing database cells, moved from corpus into one new part; the variant/lane lists and profile arguments are unchanged. Each new part receives the common bootstrap and pinned SDK artifacts.
• Checked the new native-process names against the existing unconditional cleanup, including all nine profile cleanup calls; resource scope, nonroot execution, limits, summaries and failure aggregation remain in place. The aggregate still consumes the combined result of each complete matrix job, so a failing new part cannot be hidden. Profile failures retain their real status while later lane work/log output continues; timing metadata does not replace the exit result.
• Exact four-file review slice, Node 22.23.4: nine selected wrapper tests pass; one preexisting test is deliberately excluded from this bounded run because it reads reserved fixture contents. Stub-Docker lane controls cover all nine profiles once, peak three concurrent servers, ordered stop/continuation, failed-profile and failed-stop behavior, and refusal without a scope. No actual native build/profile or fixture data was read/run.
• Pinned actionlint 1.7.7 passes YAML/expression checks with ShellCheck and pyflakes disabled; this does not claim those separate checks. Diff-check passes.

An initial negative name filter matched the file ancestor and therefore attempted the fixture-reading test against the deliberately fixture-free slice, failing on the missing directory. No fixture contents existed there or were retrieved. Re-ran the unchanged wrapper source with an explicit test-skip filter to keep this review within scope. This is not a waiver for the owning full CI run.

The reported 36.0→27.1-minute cycle / 395→401 runner-minutes is the owner’s hosted measurement, not independently reproduced by this review. Current-head hosted qualification is still running and must finish normally before merge; native behavioral and R2 decisions remain with their existing owners.

[rmcdaniel]

Merged at the reviewed head acafcea2d as 8c1c07ea0 (General's bounded review: 6392062240).

The cycle on acafcea2d (run 40151134683) had one failure, unrelated to this change: postgres-storage (postgres-17, cohorts), corrected cohort case python-clock-genuine-one (false !== true). The cohorts part is untouched here, and the same job passed on 5287ee95b. Rerunning only that job (attempt 2) passed. Two single-job flakes in two cycles (that one, and the MariaDB sdk-queries transport status 0 on attempt 1 of the first run) go on the flake record in #754.

The main cycle on 8c1c07ea0 is the first post-merge measurement; I'll add its wall time here.

[rmcdaniel]

Post-merge measurement on main at 8c1c07ea0 (run 40154225980): terminal success, 34 jobs, 27.2 min wall (vs 36.0 before), 420 runner-minutes. The long pole is now the cohorts part, 20.5 to 22.0 min. The next split, the corrected-marker cohort as its own part, is prepared on rust-325-wip/ci-corrected-part and will follow #748.