bug: Warn about Azure OpenAI completions file-incompatibility#4048
bug: Warn about Azure OpenAI completions file-incompatibility#4048
Conversation
docs/input.md
Outdated
| A model API may be unable to download a file (e.g., because of crawling or access restrictions) even if it supports file URLs. For example, [`GoogleModel`][pydantic_ai.models.google.GoogleModel] on Vertex AI limits YouTube video URLs to one URL per request. In such cases, you can instruct Pydantic AI to download the file content locally and send that instead of the URL by setting `force_download` on the URL object: | ||
| ??? warning "`DocumentUrl` and `BinaryContent` documents are not supported when using `AzureProvider` with `OpenAIChatModel`." | ||
| Use [`OpenAIResponsesModel`][pydantic_ai.models.openai.OpenAIResponsesModel] with [`AzureProvider`][pydantic_ai.providers.azure.AzureProvider] instead: |
There was a problem hiding this comment.
I don't think we need an example here, but I want to make sure the Azure doc (currently section on the OpenAI page) explains (in a generic way) that it can be used with the Responses API as well, and that that's actually recommend over OpenAIChatModel. Can you add it there instead please?
Docs Preview
|
docs/input.md
Outdated
| | [`BedrockConverseModel`][pydantic_ai.models.bedrock.BedrockConverseModel] | S3 URLs (`s3://`) | `ImageUrl`, `DocumentUrl`, `VideoUrl` | `AudioUrl` | | ||
|
|
||
| A model API may be unable to download a file (e.g., because of crawling or access restrictions) even if it supports file URLs. For example, [`GoogleModel`][pydantic_ai.models.google.GoogleModel] on Vertex AI limits YouTube video URLs to one URL per request. In such cases, you can instruct Pydantic AI to download the file content locally and send that instead of the URL by setting `force_download` on the URL object: | ||
| ??? warning "`DocumentUrl` and `BinaryContent` documents are not supported when using `AzureProvider` with `OpenAIChatModel`." |
There was a problem hiding this comment.
I'd rather add a Notes column to the table, like we have on the builtin tools doc, where we can state on the OpenAIChatModel row that Azure doesn't support it, and any other notes for provider-specific support (I believe there are some profile flags for specific providers that enable file types that are not supported by OpenAI itself)
There was a problem hiding this comment.
Instead of adding a fifth column, what about mentioning the Azure case under "Unsupported", and then linking to the section that explains the responses workaround?
docs/input.md
Outdated
| A model API may be unable to download a file (e.g., because of crawling or access restrictions) even if it supports file URLs. For example, [`GoogleModel`][pydantic_ai.models.google.GoogleModel] on Vertex AI limits YouTube video URLs to one URL per request. In such cases, you can instruct Pydantic AI to download the file content locally and send that instead of the URL by setting `force_download` on the URL object: | ||
| ??? warning "`DocumentUrl` and `BinaryContent` documents are not supported when using `AzureProvider` with `OpenAIChatModel`." | ||
| Use [`OpenAIResponsesModel`][pydantic_ai.models.openai.OpenAIResponsesModel] with [`AzureProvider`][pydantic_ai.providers.azure.AzureProvider] instead: |
There was a problem hiding this comment.
I don't think we need an example here, but I want to make sure the Azure doc (currently section on the OpenAI page) explains (in a generic way) that it can be used with the Responses API as well, and that that's actually recommend over OpenAIChatModel. Can you add it there instead please?
a01c883 to
63d7e6d
Compare
| ) | ||
|
|
||
|
|
||
| async def test_yaml_document_as_binary_content_input(allow_model_requests: None, openai_api_key: str): |
There was a problem hiding this comment.
Why did we need these new tests?
There was a problem hiding this comment.
The YAML VCR tests (test_yaml_document_as_binary_content_input, test_x_yaml_document_as_binary_content_input, test_yaml_document_url_input) cover the YAML text-like media type handling added in this PR (the new application/yaml and application/x-yaml branches in _is_text_like_media_type).
test_is_text_like_media_type is a unit test for branch coverage of _is_text_like_media_type.
test_video_url_not_supported replaces a pragma: no cover that was on the VideoUrl raise — now that branch is tested directly.
There was a problem hiding this comment.
These tests cover YAML media-type edge cases I discovered while investigating how Azure handles different file types. They validate pre-existing behavior that was untested, ensuring the content-type classification works correctly for YAML variants (application/x-yaml, text/yaml, etc). Happy to split them out if you prefer, but they're directly related to the file handling work in this PR.
There was a problem hiding this comment.
OK that makes sense, happy to have them here then
- Rename `openai_chat_supports_file_input` → `openai_chat_supports_document_input` - Rename `_raise_file_input_not_supported_error` → `_raise_document_input_not_supported_error` - Update docstrings and comments to say "document" instead of "file" - Remove duplicated paragraph in docs/models/openai.md - Replace warning box with footnote in docs/input.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The test was failing in CI because SSRF protection resolves raw.githubusercontent.com to an IP, causing VCR host matcher to fail. Adding disable_ssrf_protection_for_vcr fixture fixes this, consistent with all other URL-downloading VCR tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Covers previously uncovered lines 1233 and 1259 in openai.py: - Azure + DocumentUrl → Azure-specific error (L1233 + L1255) - Generic provider + DocumentUrl → generic error (L1233 + L1259) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| ) | ||
|
|
||
|
|
||
| async def test_yaml_document_as_binary_content_input(allow_model_requests: None, openai_api_key: str): |
There was a problem hiding this comment.
As DouweM already noted, these YAML tests (test_yaml_document_as_binary_content_input, test_x_yaml_document_as_binary_content_input, test_yaml_document_url_input) test pre-existing YAML media type handling that's already on main — they don't cover any new behavior introduced by this PR. They also bring along ~1100 lines of cassette recordings. Unless there's a specific reason to add them here (e.g. they were missing and this is a good opportunity), they'd be better suited for a separate PR to keep this one focused on the Azure document input limitation.
… version Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| ) | ||
|
|
||
|
|
||
| async def test_yaml_document_as_binary_content_input(allow_model_requests: None, openai_api_key: str): |
There was a problem hiding this comment.
OK that makes sense, happy to have them here then
|
This PR is stale, and will be closed in 7 days if no reply is received. |
…upport # Conflicts: # pydantic_ai_slim/pydantic_ai/models/openai.py # tests/models/test_openai.py # tests/test_examples.py
There was a problem hiding this comment.
🚩 Potential bypass of document support check when openai_chat_supports_file_urls=True
In _map_document_url_item at pydantic_ai_slim/pydantic_ai/models/openai.py:1245, the first branch checks not item.force_download and profile.openai_chat_supports_file_urls and returns a File content part directly WITHOUT checking openai_chat_supports_document_input. If a provider were configured with openai_chat_supports_file_urls=True AND openai_chat_supports_document_input=False, the document support check would be bypassed. Currently no provider has this combination (only OpenRouter sets openai_chat_supports_file_urls=True, and it supports documents), so this is not a practical issue today. But it's a latent inconsistency that could matter if a new provider is added with this combination.
(Refers to line 1245)
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
IMO the openai_chat_supports_file_urls flag inherently implies the provider supports documents, so I don't think we need to explicitly handle the combination
for future reference, if we found these inconsistencies, having a single dataclass that uses property to validate combinations would be a better approach than checking multiple flags, since adding a check branch here would bloat this out further
Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com>



AzureOpenAImodels don't support files #4035Pre-Review Checklist
make formatandmake typecheck.Pre-Merge Checklist