## Summary Structured output calls do not fail when the supplied JSON schema is itself invalid. A schema whose `required` array lists a key that is not defined in `properties` is forwarded to the Azure API and the call succeeds, so the caller never learns that the schema is broken. The schema below should not be usable — `description` is listed as required but never defined, while `caption` is defined but never required: ```json { "type": "object", "properties": { "alt": { "type": "string", "description": "Concise alt text for accessibility (max 125 characters)" }, "caption": { "type": "string", "description": "Concise summary (do not end with a period)" }, "title": { "type": "string", "description": "Brief title or name of the image subject" } }, "required": [ "alt", "description", "title" ] } ``` ## Steps to reproduce 1. Configure the Azure provider against a chat deployment that supports structured output. 2. Build a `ChatInput` and pass the schema above to `setChatStructuredJsonSchema()` (or use the structured output field in AI API Explorer). 3. Run the chat call. ## Expected result The invalid schema is rejected: either locally, before the request is sent, or by surfacing the API 4xx as a typed AI exception (`AiBadRequestException`) with the API message intact. ## Actual result No exception is thrown. The request goes through, a normal `ChatOutput` comes back, and the mismatch between `required` and `properties` is silently ignored. ## Analysis Line references against `1.2.x` at `826006a`. Three things combine: 1. `src/Plugin/AiProvider/AzureProvider.php:369-374` forwards `$input->getChatStructuredJsonSchema()` verbatim into `response_format.json_schema`, with no validation of the schema content. 2. `\Drupal\ai\OperationType\Chat\ChatInput::setChatStructuredJsonSchema()` normalizes `strict` to `FALSE` whenever the caller does not set it explicitly. With `strict: false`, the Azure/OpenAI API does not enforce that every key in `required` exists in `properties` either — so nothing in the whole chain catches it. 3. Even when the API does return a 4xx, the error is mangled rather than surfaced. `src/Client/ChatClient.php:148-152` catches every exception raised by the Guzzle POST and rethrows it as `\Exception("Connection error: " . $e->getMessage())`, so a schema validation 400 is reported as a connection error, with the API body truncated by Guzzle. If `connectionExceptions` is `FALSE`, the exception is swallowed entirely, `$response` stays `NULL`, and `$response->getStatusCode()` on `ChatClient.php:154` fatals instead. The provider catch block at `AzureProvider.php:394-406` only pattern-matches rate limit and quota strings, so no 4xx is ever mapped to `AiBadRequestException`. ## Proposed resolution - Validate the schema before sending. At minimum, assert that every entry in `required` is defined in `properties`, recursively for nested objects and array items, and throw `AiBadRequestException` naming the offending keys. - Preserve the API error in `ChatClient`: distinguish a Guzzle `RequestException` that carries a response from a genuine connection failure, read the response body, and rethrow with the API message so a 400 stays a 400. Guard `$response` against `NULL` before calling `getStatusCode()`. - Map 4xx responses to `AiBadRequestException` in `AzureProvider` so callers get a typed exception. Worth deciding before writing the fix: the same verbatim passthrough exists in `\Drupal\ai\Base\OpenAiBasedProviderClientBase` (around line 339), so schema validation may belong in the ai module rather than being duplicated per provider. The error handling improvements in points 2 and 3 above are Azure specific either way. ## Environment - Drupal version: 11.3.16 - Module version: 1.2.x-dev (`826006a`) - drupal/ai version: 1.4.7 - PHP version: 8.3 ### Azure configuration - Azure service: Azure OpenAI - Operation: chat (structured output) - API version: not captured - Deployment name and model ID: not captured - Custom consumer or additional headers in use: no