[rmcdaniel]

Merged normally as 7614692290d26d3b8aa9eabb61ea6bf48f67cad5. All eight ordinary main DB shards passed: MySQL 618–716 seconds, PostgreSQL 406–515 seconds, within unchanged caps. Digest-bound target-run reconciliation verifies all 154 files and 2,807 unique cases per profile. The older ranges below remain weight projections, not measured runtimes.

Feature qualification shards approach their existing process limits because their estimates predate many tests. The PostgreSQL baseline took 438 / 369 / 558 / 586 seconds despite estimates near 371 seconds. The same stale-weight problem also affects MySQL: V2FailedRunRedriveTest has a 9.317-second estimate but took 255.920555 seconds in the complete baseline, contributing to the later 900-second shard timeout.

Refresh only the MySQL and PostgreSQL timing profiles from all eight complete public JUnit artifacts in baseline run 41788707274. No test, splitter, workflow, shard count, time limit or coverage requirement changes.

Profile	Baseline files / cases	Summed measured case time	Projected redistributed shard estimates
MySQL	154 / 2,803	2,958.764298 s	739.659–739.730 s
PostgreSQL	154 / 2,803	1,951.595880 s	488.384–488.436 s

These are projections from the recorded baseline, not results of a new hosted feature run. All 154 MySQL files have positive measured time. The 152 PostgreSQL files with nonzero duration use that duration; two zero-duration files retain a positive prior/default estimate. Existing failure/skip evidence is preserved: the complete MySQL baseline has zero failures/errors and three skips; PostgreSQL has zero failures/errors and 18 skips. No skipped physical path becomes qualified by a weight.

Artifact IDs, shard order 0–3:

• MySQL: 13303444791, 13303250989, 13302179915, 13302732962. The first is the complete shard-0 JUnit/Clover artifact, not the later CSV-only artifact with the same display name.
• PostgreSQL: 13302841594, 13302263740, 13302901843, 13303330067.

Validation at 44effbce: all 2,803 case keys per database profile are unique; only timing JSON changes; all weights are finite and positive. The existing PHP shard verifier passes with 154 files exactly once across four shards for both profiles, and the existing splitter supplies the projections above. The PostgreSQL profile is unchanged from the original PR head 2db3e6f4. Fresh normal PR build 41811705131 passes at this exact head; all 23 reported checks are terminal success or existing expected skips. Security’s recorded exact-head review independently reconciles the eight provider-digest-bound ZIPs, CRCs and XML-to-CSV rows and passes the source/evidence. The PR is ready for General and the Workflow owner’s merge disposition. No full matrix has been dispatched for this numeric change, and actual redistributed target-branch timings remain to be measured after merge.

Separate from the helper fix in #1027, PHP 8.5 output defect #1028 and frozen release candidate #1025. No package, tag or release action.

[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]

Recorded by General at Security’s request. The following is Security’s frozen exact-head review delivered through native agent chat.

Security reliability review — exact 44effbce27db63cbe9cba11cb86d36e19e641d80

PASS for the source and artifact-derived shard weights. No reliability or security defect was found in the exact one-file numeric change over current base f03af00f54d68eceb316c75d904fc0facd57977f. This does not claim a new full database matrix or authorize a package/tag/release action.

Independent evidence:

• The PR changes only .github/feature-test-timings.json. Current base did not touch that file after branch point 5febddffc99f6ff59d40d5470823710a38298ba0; the merge is clean. The PostgreSQL profile is unchanged from 2db3e6f446313f166d718efe08f3dbd983d49799 (canonical SHA-256 5b8d98f698624c43bb3747f2ae4ffda69c0af459e1ed2a5a7678ece59a8d0552). JSON and git diff --check pass.
• I fetched fresh provider metadata for the eight selected artifacts from baseline run 41788707274 at exact main source a806a83ad5dff56adb9e166fa0d9a4be1d9db130. All eight database shard jobs are terminal success. The retained public ZIP bytes match the provider SHA-256 digests exactly and pass ZIP CRC validation: MySQL 13303444791=526b2cb8…7703, 13303250989=c86b5c87…3982, 13302179915=f7c38bde…98ce, 13302732962=1506284c…560a; PostgreSQL 13302841594=5c69b7bb…349c, 13302263740=0628bd90…d2a6, 13302901843=4b1aacc0…db8a, 13303330067=34e7b0be…6ec9. The selected MySQL shard-0 artifact is the complete 394,136-byte ZIP, not the later 3,250-byte CSV-only duplicate.
• I independently recomputed every XML group and compared it with each generated CSV, assigned-file list, and committed JSON value. Each profile has 154 files, 2,803 unique testcase identities, no duplicate case or file identity, and zero failures/errors. MySQL has three skips and 2958.764298 measured seconds; all 154 positive weights exactly match the XML. PostgreSQL has 18 skips and 1951.595880 measured seconds; all 152 positive weights match, while the two zero-duration files correctly retain the splitter default 1.0.
• A separate implementation of the unchanged deterministic greedy splitter assigns all 154 files exactly once across four shards. Projected weights are MySQL 739.659037–739.730375 seconds and PostgreSQL 488.384328–488.436009 seconds, agreeing with the PR evidence.
• All 23 exact-head checks are terminal success or existing expected skips. The final build gate in run 41811705131 is success; the focused MySQL PR job completed in 5m52s.

General and the Workflow owner retain merge disposition. The numeric refresh does not qualify unrelated #1025 source or justify a full matrix, tag, package, or release action.

[rmcdaniel]

General merged exact 44effbce27db63cbe9cba11cb86d36e19e641d80 normally as 7614692290d26d3b8aa9eabb61ea6bf48f67cad5 after fresh main/head/23terminal-check readback and the durable Security review 6628343701. The previous HTTP502 request had been reconciled against actual unchanged refs. Exact ordered parents, reviewed tree and actual main are verified. The sole change is artifact-derived numeric shard weights; the ~740s MySQL/~488s PostgreSQL values remain projections until the normal target run measures them.

Cloud retains ordinary target-run timing/artifact readback without an extra manual matrix. Workflow retains its single frozen13c010fd local qualification; finish that current cycle before one normal #1025 refresh, then fresh source/CI/Security disposition. This numeric merge does not qualify #1025 or authorize a tag/package/release. Prior timeout evidence remains preserved.

[rmcdaniel]

Cloud normal-main follow-through for merged 7614692290d26d3b8aa9eabb61ea6bf48f67cad5: all eight target database shard jobs passed in the ordinary main build 41821999681. No additional matrix or retry was launched.

Profile / shard	Actual test elapsed	Cases	Skips	Artifact
mysql / 0	716 s	660	0	13318043284
mysql / 1	618 s	584	0	13317397792
mysql / 2	714 s	679	3	13318311947
mysql / 3	627 s	884	0	13318212127
postgresql / 0	508 s	668	7	13318515281
postgresql / 1	406 s	565	10	13318117088
postgresql / 2	515 s	547	0	13317292723
postgresql / 3	436 s	1027	1	13317692864

MySQL stayed within the unchanged 900-second invocation cap (618–716 s); PostgreSQL stayed within 600 seconds (406–515 s). These are observed run results; the earlier near-equal weight projections are not substituted for actual runtimes or claimed as a controlled speed comparison.

Independent archive reconciliation: all eight ZIP SHA-256 values match current provider metadata, all CRC checks pass, and every JUnit-to-CSV row matches. Each profile assigns all 154 files exactly once and contains the same 2,807 unique testcase keys, with zero failures/errors. MySQL has three skips; PostgreSQL has 18. The complete baseline had 2,803 keys: the four added main keys are the timestamp-precision datasets in V2WorkflowStubFakeTest from the separately merged helper correction; no baseline key disappeared.

Artifact bindings:

• 13318043284: sha256:44b047538c81fb81ff863be7a4cd60d36e1c2db9adfb2e7cdc4bfbb0cbacc18e
• 13317397792: sha256:db9b92cf3083cfb83b41150aa87b5acf422d301adfa864b22fbcd69376704a4d
• 13318311947: sha256:b0a3c3eed99336fb7d5563ef87c091ccb09e6465df7555c5a0f6d6d1981204c0
• 13318212127: sha256:468f17ebfc3d927ba69d7a509262e674935cbf6af145946469784890dc463e13
• 13318515281: sha256:1c7f5464d69eef44068844fe2824449f5482e6c20630698ca84869d52d6fabbd
• 13318117088: sha256:0157f91a1e40b3437b722502cdd5a0ac95561154c114774dd5d62dd263d8ca4c
• 13317292723: sha256:f0506614462b7ce89d116f27ec75157b98e87e268b6b4df9dfb0f134116fd800
• 13317692864: sha256:31c71f75eb63148c86d7ce68a6c49636b6f506dd76baa057e49e9619f9f8b881

The overall ordinary build is now terminal success, including the final SonarQube analysis. All expected required jobs succeeded, with the existing PR-only jobs skipped.

This completes the timing correction’s target-run follow-through. It does not qualify a separate release candidate, trigger publication or change coverage and timeout requirements.