AI: Return false from support checks when the wrapped builder throws

[jigneshbhavani]

WP_AI_Client_Prompt_Builder::__call() catches an exception from the wrapped SDK builder, stores it as the error state, and then only special cases the generating methods:

} catch ( Exception $e ) {
	$this->error = $this->exception_to_wp_error( $e );

	if ( self::is_generating_method( $name ) ) {
		return $this->error;
	}
	return $this;
}

is_supported() and the seven is_supported_for_*() methods are not generating methods, so they fall through to the fluent return and give back the builder instance. It is truthy, so a support check that failed reads as a success:

if ( wp_ai_client_prompt( 'Write a haiku' )->is_supported() ) {
	// Runs even though the support check could not be completed.
}

Everywhere else in the class this is handled. The error state guard at the top of __call() returns false for support checks, and so does the prevented prompt path. Only an exception raised during the support check itself takes the wrong branch.

Reproducing it

ModalityEnum::document() is a documented factory, but PromptBuilder::inferCapabilityFromOutputModalities() has no branch for it and throws a RuntimeException in its else. That call is outside the try block isSupported() uses to swallow InvalidArgumentException, so it reaches the wrapper.

$result = wp_ai_client_prompt( 'Test text' )
	->as_output_modalities( ModalityEnum::document() )
	->is_supported();

var_dump( $result ); // object(WP_AI_Client_Prompt_Builder), expected bool(false)

Any throw from the wrapped builder during a support check behaves the same way. The document modality is just the shortest route to one.

Fix

Return false for support check methods from the catch block, so they match what they already return when the builder was in an error state beforehand. The error is still stored, so a later generating call still gets the WP_Error, and the test covers that.

Not a duplicate of #65505

#65505 is about the catch missing Error. Its patch widens catch ( Exception ) to catch ( Throwable ) and leaves the return logic untouched, so a support check still comes back as the builder after it lands. The two changes are independent and touch different lines.

Testing

test_support_check_methods_return_false_when_builder_throws() fails on trunk with:

Failed asserting that WP_AI_Client_Prompt_Builder Object (... 'error' => WP_Error ...
  'Output modality "document" is not yet supported.') is of type "bool".

and passes with the patch. The full ai-client group is green, 258 tests. phpcs passes on both changed files.

Trac ticket: https://core.trac.wordpress.org/ticket/65781

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Reading through the AI client for places where the code disagrees with its own documented behaviour, which is how this turned up, and drafting this description. I confirmed the throw path in the bundled client myself, wrote and ran the test, checked it fails without the patch, ran phpcs, and I take responsibility for the change.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props bejignesh, irozum, gziolo.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[Copilot]

Pull request overview

Fixes WP_AI_Client_Prompt_Builder::__call() so support-check methods (is_supported() / is_supported_for_*()) return false when the wrapped SDK PromptBuilder throws during the support check itself, matching existing behavior for pre-existing error states and prevented prompts.

Changes:

• Return false (instead of the fluent builder instance) from __call()’s exception handler when the invoked method is a support-check method.
• Add a PHPUnit regression test covering the thrown-during-support-check scenario and verifying the stored error is still returned by generating methods.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/wp-includes/ai-client/class-wp-ai-client-prompt-builder.php	Adjusts __call() catch behavior so support checks fail closed (false) when the wrapped builder throws.
tests/phpunit/tests/ai-client/wpAiClientPromptBuilder.php	Adds a regression test for support-check behavior when the wrapped builder throws, and asserts error-state propagation to generating methods.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[gziolo]

Thanks, this looks good. I applied the patch locally: the full ai-client group passes (266 tests), all 9 new tests fail with only the src/ change reverted, and phpcs and phpstan are clean.

The fix makes the catch block match the error state guard above it, which is the behavior the class already documents. Nice catch.

Since the patch settles what support checks return, three docblocks could be updated in the same commit:

1. Line 82: @method bool|WP_Error is_supported(...) should be @method bool is_supported(...). No code path can return a WP_Error here, so this annotation is simply wrong. The other seven support checks are already bool.

2. The __call() docblock says the method "returns a WP_Error when a terminate method is called". It could also say that support check methods return false.

3. The class docblock says all later calls "return the same error state instance". Support checks return false instead. This one is already true on trunk, so it is an old gap, not something you introduced.

Only the first is a real error. The other two are prose that drifted.

[jigneshbhavani]

All three applied in 69fc18c.

On the first one, bool|WP_Error was never reachable, including before this patch. Every support check path returns a bool: the error state guard and the prevented prompt branch both return false, the success path returns what the wrapped builder returns, and the catch block returned $this before this change and returns false after it. Nothing in src/ calls is_supported() outside the class, so the annotation was wrong without anything depending on it.

The __call() docblock now reads "returns a WP_Error when a terminate method is called, or false when a support check method is called", and the class docblock notes that support checks return false rather than the error state instance.

phpcs and phpstan are clean and the ai-client group passes at 266 tests.

[gziolo]

Thank you for addressing feedback.

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 63298
GitHub commit: 9120bb6

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.