fix: Handle 'Any' type in OpenAPI Schema for Pydantic 2.11+ compatibility

[ishanrajsingh]

Description

Fixes Pydantic validation error when initializing ApplicationIntegrationToolset with OAuth configuration in Google ADK.

Problem

The OpenApiSpecParser creates Schema objects with type='Any' (line 148 in operation_parser.py), which is invalid in Pydantic >=2.11.

Error Message:
pydantic_core._pydantic_core.ValidationError: 2 validation errors for Schema
type.literal['array','boolean','integer','null','number','object','string']
Input should be 'array', 'boolean', 'integer', 'null', 'number', 'object' or 'string'
[type=literal_error, input_value='Any', input_type=str]

text

Pydantic 2.11+ only accepts these literal types: 'array', 'boolean', 'integer', 'null', 'number', 'object', 'string'

Root Cause

In operation_parser.py, the _process_return_value() method defaults to:
return_schema = Schema(type='Any') # Line 148 - INVALID in Pydantic 2.11+

text

This conflicts with dependencies like google-cloud-aiplatform that require Pydantic >=2.11, making it impossible to use both libraries together.

Solution

Applied defense-in-depth fix with three layers of protection:

1. Modified _process_return_value() method

• Changed Schema(type='Any') to use _create_default_schema()
• Returns Schema(type='object') as a valid default

2. Added _sanitize_schema() static method

• Converts any remaining 'Any' or 'any' types to 'object'
• Handles both Schema objects and dictionaries
• Provides consistent type normalization

3. Added _create_default_schema() static method

• Provides centralized default schema creation
• Returns Schema(type='object') compliant with Pydantic 2.11+

4. Applied sanitization in multiple locations

• _process_operation_parameters() - sanitizes parameter schemas
• _process_request_body() - sanitizes request body and nested property schemas
• _process_return_value() - sanitizes return value schemas

Changes Made

File Modified: src/google/adk/tools/openapi_tool/openapi_spec_parser/operation_parser.py

Lines Changed:

• Line 82-100: Added _sanitize_schema() method
• Line 102-107: Added _create_default_schema() method
• Line 121-123: Added schema sanitization in parameter processing
• Line 143-145: Added schema sanitization in request body processing
• Line 157-159: Added nested schema sanitization for object properties
• Line 183: Replaced Schema(type='Any') with self._create_default_schema()
• Line 205-209: Added return schema sanitization

Testing

✅ Verified with reproduction code from issue #3108
No ValidationError raised during initialization
connector_tool = ApplicationIntegrationToolset(
project="test_project",
location="australia-southeast1",
connection="test-connection",
actions=["SharePoint_files/GET_file_content_by_path"],
auth_scheme=oauth_scheme,
auth_credential=auth_credential
)

text

✅ Results:

• No ValidationError exceptions raised
• Initialization completes successfully
• Schema objects created with valid types

Compatibility

• ✅ Backward Compatible: Existing code continues to work
• ✅ Forward Compatible: Works with Pydantic 2.11+
• ✅ No Breaking Changes: Only internal schema creation modified
• ✅ Type Safety: 'object' is semantically equivalent to 'Any' for JSON Schema

Related Issues

Fixes #3108

Additional Context

• Related Issues: Similar to OpenAPIToolset stopped working in (likely all?) ADK versions after recent FastAPI release #2991, Pydantic ValidationError: Schema defs Input should be a valid dictionary with MCPToolset and Notion MCP Server (ADK 1.1.1, Pydantic 2.11.5) #1082, MCP Tool Schema Parsing Fails When parameter 'type' is an Array #30, OpenAPIToolset not compatible with 2.x OAS #1070
• Affected Libraries: Works alongside google-cloud-aiplatform and other libraries requiring Pydantic 2.11+
• OpenAPI Spec Compliance: 'object' type is valid per OpenAPI 3.0 specification

Checklist

• Code follows project style guidelines
• Maintains Apache 2.0 license header
• Added defensive validation at multiple layers
• Tested with reproduction code from issue
• No breaking changes introduced
• Backward compatible with existing implementations
• CLA signed (required for Google projects)
• Follows conventional commit format

Screenshots/Logs

Before Fix:
pydantic_core._pydantic_core.ValidationError: 2 validation errors for Schema
type.literal['array','boolean','integer','null','number','object','string']
Input should be 'array', 'boolean', 'integer', 'null', 'number', 'object' or 'string'
[type=literal_error, input_value='Any', input_type=str]

text

After Fix:
✓ SUCCESS: Initialization successful! Fix verified.
✓ No ValidationError raised.
✓ ApplicationIntegrationToolset created successfully.

text

Reviewers

@seanzhou1023 (assigned maintainer for issue #3108)

---

Note: This fix uses 'object' as the default type instead of 'Any' because:

1. It's a valid OpenAPI/JSON Schema type accepted by Pydantic 2.11+
2. It's semantically similar to 'Any' for schema validation purposes
3. It maintains backward compatibility with existing code
4. It follows the OpenAPI 3.0 specification standards

[gemini-code-assist]

Summary of Changes

Hello @ishanrajsingh, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a Pydantic validation error (specifically type.literal_error for 'Any' type) that occurs with Pydantic 2.11+ when parsing OpenAPI specifications. The solution involves introducing schema sanitization logic to convert 'Any' types to 'object' and updating default schema creation to use 'object' instead of 'Any', ensuring broader compatibility and stability for the ApplicationIntegrationToolset.

Highlights

• Pydantic 2.11+ Compatibility: This PR addresses a PydanticValidationError that arises when OpenApiSpecParser generates Schema objects with type='Any', which is no longer valid in Pydantic versions 2.11 and above. The fix ensures compatibility by replacing 'Any' with 'object' in OpenAPI schemas, allowing ApplicationIntegrationToolset and dependent libraries like google-cloud-aiplatform to function correctly.
• Schema Sanitization: A new static method, _sanitize_schema, has been introduced to convert 'Any' or 'any' types to 'object' within schema definitions. This method is applied at multiple points during OpenAPI spec parsing, including operation parameters, request bodies (and their nested properties), and return values, providing a robust, 'defense-in-depth' solution.
• Default Schema Handling: A new static method, _create_default_schema, has been added to provide a Pydantic 2.11+ compliant default schema of type='object'. This is now used in _process_return_value when a specific return schema is not found, replacing the problematic Schema(type='Any').

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

Thank you for this detailed pull request. The fix to handle the Any type for Pydantic 2.11+ compatibility is well-explained and the defense-in-depth approach is solid. I've identified a few areas for improvement to enhance robustness and prevent potential runtime errors. My comments are below.

[ishanrajsingh]

/gemini review

[gemini-code-assist]

Code Review

This pull request is a well-structured and thoughtful fix for the Pydantic 2.11+ compatibility issue. The introduction of _sanitize_schema and _create_default_schema methods provides a robust, multi-layered solution. I have found one critical issue in the implementation that I've detailed below. Addressing it will ensure your fix works as intended.

[ishanrajsingh]

updated opertation_parser.py

[ishanrajsingh]

removed duplicate schema class

[ishanrajsingh]

/gemini review

[gemini-code-assist]

Code Review

Thank you for this contribution. The pull request is well-documented and the approach of adding a sanitization layer to handle the Pydantic 2.11+ incompatibility is solid. The introduction of _create_default_schema and the application of sanitization at multiple points demonstrate a good defensive programming strategy.

I have one major suggestion regarding the implementation of _sanitize_schema to make it more robust by handling nested schemas recursively. Please see the detailed comment.