Fix: auto update check error should not fail the running command

[Copilot]

When the background update check hits a network/HTTP error (e.g. 401, 403 rate-limit), CLI_Command::get_updates() calls WP_CLI::error(), which exits the process — silently killing whatever command the user actually ran.

Changes

• Runner::auto_check_update(): Replace the bare ob_start() / WP_CLI::run_command() pattern with WP_CLI::runcommand() using exit_error => false and return => 'all'
  • exit_error => false sets $capture_exit = true so WP_CLI::error() throws ExitException instead of calling exit()
  • return => 'all' swaps in an Execution logger that captures stdout/stderr in memory — the error message is never printed to the terminal
  • On failure, a WP_CLI::debug() message is emitted (visible with --debug) and the check silently returns without affecting the user's command

// Before: any HTTP error in get_updates() would call exit(1)
ob_start();
WP_CLI::run_command( [ 'cli', 'check-update' ], [ 'format' => 'count' ] );
$count = ob_get_clean();

// After: errors are captured, not propagated
$result = WP_CLI::runcommand(
    'cli check-update --format=count',
    [ 'launch' => false, 'exit_error' => false, 'return' => 'all' ]
);
if ( ! is_object( $result ) || $result->return_code ) {
    WP_CLI::debug( 'Background update check failed: ' . ( is_object( $result ) ? trim( $result->stderr ) : '' ), 'auto-update' );
    return;
}

Summary by CodeRabbit

• Bug Fixes
  • Prevented automatic update checks from disrupting unrelated CLI commands when the releases service is rate-limited or unreachable.
  • Improved resilience of background update detection so failures no longer cause non-update commands to exit non-zero.
• Tests
  • Added coverage for the “rate limit exceeded” case and confirmed update checks don’t affect commands like wp help, including when auto-check timing is disabled.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
php/WP_CLI/Runner.php	0.00%	9 Missing ⚠️

📢 Thoughts on this report? Let us know!

[schlessera]

At first glance, wp help in an empty dir makes sense, that path does call auto_check_update(). But I don't think this scenario actually exercises the fix: auto_check_update() bails out well before the check-update call, first on ! inside_phar() (Behat runs from source, not a Phar) and then on ! posix_isatty( STDOUT ) (Behat pipes STDOUT, so it's never a TTY). So the runcommand is never reached, and the 403 mock is never hit by the auto path. Quickest way to confirm: revert the Runner.php hunk and this scenario still passes. That's also why codecov/patch is red, the new branch gets no coverage.

I'd rather we either drop this scenario (the manual repro in the PR description is the real evidence, and a green check that guards nothing is worse than no check), or, if we want genuine coverage, pull the 'run check-update and interpret the result' core out into a testable seam and unit-test it with a mocked runcommand. A full feature test would need a test-only bypass of the Phar/TTY guards, which I don't think is worth it here.

[schlessera]

Minor: with return => 'all', runcommand always hands back the object, so ! is_object( $result ) can't actually be true here. Harmless as defensive code, so feel free to leave it.

[schlessera]

Tiny thing: runcommand already trims stderr on the way out (it builds the all object with trim( $stderr )), so the trim() here is redundant.