Summary
wp-playground-cli run-blueprint can collapse a Blueprint runPHP fatal into a blank CLI error:
The PHP failure does happen and the process exits non-zero, but the CLI formatter drops the useful cause chain when the top-level Error has an empty message.
Minimal reproduction
Save this as fatal-runphp.json:
{
"steps": [
{
"step": "runPHP",
"code": "<?php require_once '/wordpress/wp-load.php'; playground_cli_missing_probe_function();"
}
]
}Run:
wp-playground-cli run-blueprint --blueprint fatal-runphp.json --wp latest --php 8.3 --verbosity=debug
Expected result
The CLI should surface the Blueprint step failure and PHP fatal details, e.g.:
Error: Error when executing the blueprint step #1: PHP.run() failed with exit code 255.
=== Stdout ===
Fatal error: Uncaught Error: Call to undefined function playground_cli_missing_probe_function()
Actual result
Evidence
A reusable Homeboy rig was added to reproduce and measure this path:
Baseline metrics:
control_exit_code=0
fatal_exit_code=1
fatal_blank_error=1
fatal_has_php_diagnostic=0
The control Blueprint proves the CLI/Blueprint path is otherwise functional. The fatal Blueprint proves the command exits non-zero but does not expose PHP diagnostics.
A candidate formatter-only fix was verified with the same rig:
- Candidate run:
52652822-759d-438c-a56e-8d4b6605dc33
Candidate metrics:
control_exit_code=0
fatal_exit_code=1
fatal_blank_error=0
fatal_has_php_diagnostic=1
Root cause
describeError() in the CLI returns error.message immediately for Error instances. In this failure path, the top-level Error has an empty message, but its cause contains the useful Blueprint/PHP failure details. Since the formatter does not inspect cause when message is empty, the CLI prints only Error:.
Related
This is adjacent to broader PHP fatal diagnostic issues such as #2278, but this issue is specifically about CLI formatting losing details that are already present in the error cause chain.
Summary
wp-playground-cli run-blueprintcan collapse a BlueprintrunPHPfatal into a blank CLI error:The PHP failure does happen and the process exits non-zero, but the CLI formatter drops the useful cause chain when the top-level
Errorhas an emptymessage.Minimal reproduction
Save this as
fatal-runphp.json:{ "steps": [ { "step": "runPHP", "code": "<?php require_once '/wordpress/wp-load.php'; playground_cli_missing_probe_function();" } ] }Run:
Expected result
The CLI should surface the Blueprint step failure and PHP fatal details, e.g.:
Actual result
Evidence
A reusable Homeboy rig was added to reproduce and measure this path:
79d1d8c6-0bb5-4abb-8e18-5467e708cff2Baseline metrics:
The control Blueprint proves the CLI/Blueprint path is otherwise functional. The fatal Blueprint proves the command exits non-zero but does not expose PHP diagnostics.
A candidate formatter-only fix was verified with the same rig:
52652822-759d-438c-a56e-8d4b6605dc33Candidate metrics:
Root cause
describeError()in the CLI returnserror.messageimmediately forErrorinstances. In this failure path, the top-levelErrorhas an emptymessage, but itscausecontains the useful Blueprint/PHP failure details. Since the formatter does not inspectcausewhenmessageis empty, the CLI prints onlyError:.Related
This is adjacent to broader PHP fatal diagnostic issues such as #2278, but this issue is specifically about CLI formatting losing details that are already present in the error cause chain.