>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3562514. --> Reported by: [julitroalves](https://www.drupal.org/user/2413556) Related to !25 >>> <h2>Problem</h2> <p>-------<br> AzureProvider::chat() has the signature:</p> <p> chat(array|string|ChatInput $input, string $model_id, array $tags = [])</p> <p>All three input types are legitimate. The flat array form in particular is<br> a supported shape -- see #3554046, which added flat message structure<br> support -- and chat() handles it correctly at first: $chat_input = $input<br> is passed straight through into $payload['messages'] with no conversion,<br> because a flat array is already in the wire format Azure expects.</p> <p>Immediately after building the payload, however, two unguarded calls are<br> made against $input (src/Plugin/AiProvider/AzureProvider.php, 1.2.x):</p> <p> line 353: if (method_exists($input, 'getChatTools') &amp;&amp; ...<br> line 360: if (method_exists($input, 'getChatStructuredJsonSchema') &amp;&amp; ...</p> <p>Under PHP 8, method_exists() throws a TypeError when its first argument is<br> an array, so any caller passing a flat message array gets an uncaught<br> fatal:</p> <p> method_exists(): Argument #1 ($object_or_class) must be of type<br> object|string, array given</p> <p>This is a fatal (WSOD / HTTP 500), not a warning, and it fires on a<br> documented, supported input form -- so flat-array chat is currently<br> completely broken on Azure.</p> <p>The string input form does not fatal, but is also wrong: method_exists()<br> interprets a string as a class name, so it silently attempts a class<br> lookup on the prompt text and returns FALSE.</p> <p>These are the only two unguarded method_exists() calls in the module.</p> <h2>Steps to reproduce</h2> <p>------------------<br> Call the Azure provider's chat operation with a flat array rather than a<br> ChatInput object:</p> <p> $provider = \Drupal::service('ai.provider')<br> -&gt;createInstance('ai_provider_azure');<br> $provider-&gt;chat([<br> ['role' =&gt; 'user', 'content' =&gt; 'Hello'],<br> ], 'your_chat_model_id');</p> <p>Result: TypeError as above. Passing the same messages wrapped in a<br> ChatInput works.</p> <h2>Proposed resolution</h2> <p>-------------------<br> Guard both calls so the tools and structured-JSON branches only run for<br> object input. Minimal fix, matching MR !25:</p> <p> if (is_object($input) &amp;&amp; method_exists($input, 'getChatTools') &amp;&amp; ...<br> if (is_object($input) &amp;&amp; method_exists($input, 'getChatStructuredJsonSchema') &amp;&amp; ...</p> <p>Alternative worth a maintainer opinion: both methods are declared only on<br> Drupal\ai\OperationType\Chat\ChatInput (getChatTools() at line 286,<br> getChatStructuredJsonSchema() at line 234), so</p> <p> if ($input instanceof ChatInput &amp;&amp; $input-&gt;getChatTools()) { ... }</p> <p>is exact and cheaper. The tradeoff is that method_exists() is duck-typed<br> and so tolerates a custom non-ChatInput object that exposes the same<br> methods; instanceof would silently stop honouring tools for such a caller.<br> Given this module already supports custom consumers, I lean towards the<br> is_object() guard to preserve that tolerance. Maintainer call.</p> <h2>Pending</h2> <p>-------<br> * Consider also guarding the string case explicitly, or documenting that<br> string input never carries tools.<br> * Test coverage: a chat() call with flat-array input would have caught<br> this and there is currently none.</p>