Core AI: Title regeneration fails with cURL timeout and exposes full HTML in console (WP 7.0 RC)

[PriyankaGusani]

Description

When testing the Core AI feature in WordPress 7.0 RC, I encountered an issue while regenerating a post title.

Actual behavior:

A network error occurs:

cURL error 28: Operation timed out after 30006 milliseconds with 0 bytes received
In the browser console:
A 500 Internal Server Error is logged
The response unexpectedly includes the entire HTML of the page

Also noticed:
wp.abilities.executeAbility is unavailable. Falling back to REST.

Why this is an issue:

Returning full HTML in API response may indicate improper error handling
Could expose unintended data or create debugging/security concerns

Additional Notes:

Issue seems related to the request sent to:

https://router.huggingface.co/v1/chat/completions
Possibly caused by API timeout, but response handling appears incorrect

Step-by-step reproduction instructions

1. Created a new post
2. Entered blog title and content
3. Clicked on “Re-generate” title option
4. Checked the console log

Screenshots, screen recording, code snippet

Environment info

WordPress Version: 7.0 RC (Beta)
Feature: Core AI (Title Generation)
Browser: Chrome (latest)
Setup: Local/Development environment

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except the AI plugin.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[jamesgiroux]

Root Cause Analysis

I traced the full request path for this bug. The issue is an uncaught exception in the WordPress core REST API handler for abilities.

Request flow when it breaks:

1. Client-side (src/utils/run-ability.ts) detects wp.abilities.executeAbility is unavailable and falls back to REST
2. REST request hits POST /wp-abilities/v1/abilities/ai/title-generation/run
3. WP_REST_Abilities_V1_Run_Controller::execute_ability() (wp-includes/rest-api/endpoints/class-wp-rest-abilities-v1-run-controller.php:93) calls $ability->execute($input) — with no try-catch
4. The title generation ability calls wp_ai_client_prompt()->generate_text(), which sends an HTTP request to HuggingFace's router (the fallback provider when no API key is configured)
5. The request times out after 30s → the AI client's ResponseUtil::throwIfNotSuccessful() throws a ServerException
6. The exception propagates uncaught through the REST controller
7. WordPress renders an HTML fatal error page with a 500 status instead of a JSON error response

Why HTML instead of JSON

The REST handler only checks for WP_Error return values (line 94-96), but doesn't catch PHP exceptions. When an uncaught exception hits WordPress's default error handler, it renders HTML — hence the full page HTML in the console and the Content-Type: text/html response.

Proposed fix

In wp-includes/rest-api/endpoints/class-wp-rest-abilities-v1-run-controller.php, wrap the execute call in a try-catch:

$input = $this->get_input_from_request( $request );

try {
    $result = $ability->execute( $input );
} catch ( \Exception $e ) {
    return new WP_Error(
        'rest_ability_execution_failed',
        $e->getMessage(),
        array( 'status' => 500 )
    );
}

if ( is_wp_error( $result ) ) {
    return $result;
}

This ensures provider failures (timeouts, server errors, etc.) return a proper JSON error response that the client can handle gracefully.

Note: This fix is in WordPress core (wp-includes/), not in the AI plugin itself. A Trac ticket may be needed to land this upstream.

[jeffpaul]

@gziolo who best should we coordinate with on resolution here?

[dkotter]

In addition to a potential upstream fix, would be great to know what AI Connector was used here as that Connector may want to add support for a longer than 30 second timeout.

[gziolo]

So the same issue will apply to all custom callbacks passed to the ability that throw exceptions. There is WP_Ability::invoke_callback that could handle that gracefully, even though we didn't anticipate such a case, as it isn't documented that the callback can throw an exception. I'm happy to open a Trac ticket and propose a quick fix tomorrow.

[gziolo]

https://core.trac.wordpress.org/ticket/65058 - the ticket is ready, and the patch is coming up next.