PHPUnit recipes hang after PHP WASM mysqli_poll runtime crash

[chubes4]

Problem

PHPUnit recipes using WP Codebox 0.13.2 from main SHA b790df0c2c56b00ad80fa0342791fd278e82755c reproducibly crash inside PHP 8.3 WASM, then remain active until the 1,500,000 ms recipe timeout. No structured PHPUnit result is produced.

Evidence

Blocked consumer PR: Extra-Chill/data-machine#2991
Workflow run: https://github.com/Extra-Chill/data-machine/actions/runs/30094573746

The initial run and one failed-job retry both terminated after approximately 26m52s with the same signature:

Unhandled rejection: RuntimeError: null function or function signature mismatch
    at php.wasm._php_stream_write_filtered
    at php.wasm._php_stream_flush
    at php.wasm._php_stream_cast
    at php.wasm.mysqlnd_stream_array_from_fd_set
    at php.wasm.zif_mysqli_poll
Error [RuntimeError]: unreachable
    at php.wasm.wasm_sapi_handle_request

The recipe then reports:

Recipe run timed out after 1500001ms while waiting for workflow.steps[0]:wordpress.phpunit

Retry reports the equivalent 1500002ms timeout. Distinct runtime IDs (runtime-mryxxcrz-cois0r, runtime-mryywzlk-1ypvor) rule out one stranded runtime. Both use Node 24, PHP WASM 8.3, WP Codebox 0.13.2, and source SHA b790df0c2c56b00ad80fa0342791fd278e82755c.

Artifacts:

• Attempt 1 observations: https://github.com/Extra-Chill/data-machine/actions/runs/30094573746/artifacts/8597714987
• Attempt 2 observations: https://github.com/Extra-Chill/data-machine/actions/runs/30094573746/artifacts/8598439470

Expected behavior

A PHP WASM runtime rejection should terminalize the PHPUnit workload immediately with structured infrastructure-failure evidence. The runtime should not remain active until the full recipe timeout. The underlying mysqli_poll crash should be fixed or avoided so the Data Machine PHPUnit suite can complete.

Reproduction

From the Data Machine PR branch at 5ad0a03ecbf2f389af7aee0caf3e3e4586ef942f:

homeboy review test data-machine --changed-since 9fff571ab1a4e3a19624956c651f40193891a295

The AGENTS.md candidate changes do not touch PHPUnit runtime or database behavior. Focused tests and the independent audit, lint, refactor, plan, and prefix-policy gates pass.

[chubes4]

PR #2011 merged as 6552a47c, but the downstream rerun loaded that exact SHA and reproduced the same 1,500,002 ms timeout. The runtime listener is in the parent WP Codebox process; the real Unhandled rejection: RuntimeError ... zif_mysqli_poll is emitted by the spawned Playground CLI child, so the in-process synthetic test did not prove the production process boundary.

New evidence:

• rerun job: https://github.com/Extra-Chill/data-machine/actions/runs/30094573746/job/89540835546
• observations: https://github.com/Extra-Chill/data-machine/actions/runs/30094573746/artifacts/8604275717
• loaded source: WP_CODEBOX_SOURCE_SHA=6552a47c3d00c4d9d380efc81e682b81d5806b92

Next repair must propagate child-process runtime rejection/exit promptly through the Playground CLI protocol and include an actual child-process regression, not an in-process process.emit simulation.

[chubes4]

Corrected causal evidence from the rerun against merged PRs #2012 and #2016:

• WP Codebox source loaded: 489656a90f099c1ba6f8cf6b4e7a11967b05a62c
• wordpress.phpunit started: 2026-07-24T18:46:27.607Z
• recipe timeout recorded: 2026-07-24T19:10:02.330Z (1,500,001ms)
• Unhandled rejection: RuntimeError ... php.wasm.zif_mysqli_poll emitted: 2026-07-24T19:10:04.062Z

The PHP-WASM rejection occurs about 1.7 seconds after the recipe has already timed out, during abort/cleanup of the hung operation. It is therefore not the cause of the 25-minute wait. The worker terminalization overlay now propagates the rejection and yields structured timeout evidence, but the unresolved defect is the earlier mysqli_poll hang.

Failed job: https://github.com/Extra-Chill/data-machine/actions/runs/30094573746/job/89563325888

Reopening because the user-facing PHPUnit recipe hang remains unresolved. The next investigation must reproduce and bound the mysqli_poll stall itself rather than treating the cleanup rejection as the initiating failure.

[chubes4]

Independent bounded confirmation is now available and the distinct upstream bug is filed:

• Playground issue: PHP-WASM mysqli_poll does not honor its timeout for a pending async MySQL query WordPress/wordpress-playground#4161
• proof commit: 860bff1
• Linux/Docker run: https://github.com/Automattic/wp-codebox/actions/runs/30120500876/job/89571652650

The reproducer removes WordPress PHPUnit discovery entirely. Against a reachable disposable MySQL service, it holds an InnoDB row lock, submits a conflicting MYSQLI_ASYNC query, and calls mysqli_poll(..., 0, 100000). Expected: return 0 after ~100ms. Actual: wordpress.run-php remains pending until the 20,001ms outer timeout, followed by the same mysqlnd_stream_array_from_fd_set / zif_mysqli_poll runtime rejection.

This confirms the initiating defect is Playground PHP-WASM not honoring the bounded mysqli_poll timeout, separate from the worker rejection containment tracked in Playground #4160.