Runtime checks return HTTP 400 / body 0 while admin UI reports no errors #1445

Status: reproducible upstream/tooling incident; no evidence of an EAA plugin defect.

Environment
Plugin Check 2.1.0;
WordPress 7.0.4 on the first environment;
PHP 8.2.33, FPM/FastCGI, Apache 2.4.68 on clean.pirat.okinawa;
a second independent WordPress environment configured for PHP 8.3 on pirat.okinawa;
WordPress admin Plugin Check UI;
category: Performance.
Both sites are disposable QA installations. The report intentionally excludes credentials, nonces, cookies and response headers.

Steps to reproduce
Install and activate Plugin Check 2.1.0.
Select a plugin for which Performance discovery includes runtime checks. The issue was reproduced with P-I-R-@-T EAA Accessibility Auditor 0.8.6 on both environments and with WooCommerce on the PHP 8.2 environment.
Select only the Performance category.
Run Plugin Check while monitoring POST requests to /wp-admin/admin-ajax.php.
Expected result
Every check returned by plugin_check_get_checks_to_run is executed. A success notice is rendered only when every discovery, setup, check and cleanup request succeeds.

Actual result
Discovery returns HTTP 200 and these eight checks:

performant_wp_query_params;
enqueued_scripts_in_footer;
enqueued_resources;
enqueued_scripts_size;
enqueued_styles_size;
enqueued_styles_scope;
enqueued_scripts_scope;
non_blocking_scripts.
plugin_check_set_up_environment returns HTTP 200 with Runtime environment setup successful.. The first three static checks return HTTP 200. Each of the five runtime checks then returns HTTP 400 with the response body 0:

enqueued_scripts_size;
enqueued_styles_size;
enqueued_styles_scope;
enqueued_scripts_scope;
non_blocking_scripts.
plugin_check_clean_up_environment subsequently returns HTTP 200 with Runtime environment cleanup successful..

The admin UI may still render Checks complete. No errors found. because the individual failed check requests are caught without being reflected in the final completion state.

Cross-checks
The EAA plugin's three static Performance checks complete with no findings before the runtime requests fail.
WooCommerce reproduces the same five HTTP 400 / 0 runtime failures. Its static checks execute normally and return WooCommerce-specific findings, demonstrating that static analysis and result transport are working.
Hello Dolly is not a runtime comparison: its Performance discovery returns only the three static checks and setup reports No runtime checks, runtime environment was not setup..
The exact EAA sequence reproduces on the PHP 8.2 and PHP 8.3 WordPress installations.
Impact
The visible success state can be a false positive: five expected runtime checks were not executed successfully. Consumers should treat this combination as indeterminate, not as a pass.

Diagnostic interpretation
The response body 0 is the WordPress AJAX fallback observed when the requested action has no registered callback in that request. Since discovery, setup and cleanup succeed while every isolated runtime check fails identically across plugins and environments, the evidence points to the Plugin Check runtime bootstrap rather than to an individual checked plugin.

Thanks for repair
Ilja HYnek