fix: Add support for list-type JSON Schema fields in modeling.py#37
Merged
Conversation
added 2 commits
May 1, 2025 23:35
Problem:
- JSON Schema allows specifying multiple types using array notation: {"type": ["string", "number"]}
- This is valid per JSON Schema specification, and common in real-world schemas
- The mcpadapt modeling.py module failed with "unhashable type: 'list'" when processing such schemas
- Error occurs in get_field_type() when attempting to use a list as a dictionary key
Solution:
- Enhanced get_field_type() to properly handle list-type JSON Schema types
- Added special case to detect when json_type is a list
- Implemented conversion of list-type to Python Union types
- For single-item lists, extract and use the single type
- For multi-item lists, create a Union of all mapped types
- Preserves original behavior for all other schema types
This fix ensures compatibility with JSON Schema that use the array notation for
specifying multiple allowed types for a field, which is a common pattern in the
JSON Schema ecosystem. The fix is backwards compatible and follows the expected
behavior of properly converting JSON Schema types to their Python equivalents.
This commit adds a comprehensive test suite for validating the fix for JSON Schema array notation in type fields (e.g., "type": ["string", "number"]). Key additions: - New test file tests/test_modeling.py with multiple test scenarios: - Direct test against modeling.py to verify handling of list-type JSON Schema fields - Tests for array-type fields with multiple primitive types - Specific tests for handling of null types in array notation - Inspection utility to examine actual schema structure in MCP tools The tests are designed to: 1. Verify the fix works correctly for all edge cases 2. Provide clear diagnostics when the bug is present 3. Demonstrate proper handling of various JSON Schema type patterns 4. Ensure consistent behavior with the existing anyOf implementation The test handles both the "happy path" (with fix) and failure path (without fix), making it valuable for preventing regressions. It also improves null type handling to be consistent with how the codebase already handles nulls in anyOf constructs. This testing approach validates that our implementation correctly supports the JSON Schema specification, which allows multiple types to be specified either via array notation or anyOf constructs.
Owner
|
Hey @sakthikannan25 thanks for the PR I will review soon! |
grll
requested changes
May 7, 2025
grll
left a comment
Owner
There was a problem hiding this comment.
Sorry for your patience, this change look good just a few shuffling around and remove of some verbosity in the tests. Thanks again for your contribution!
| assert "Name: None" in result_null | ||
|
|
||
|
|
||
| def test_json_schema_array_type_with_null(json_schema_array_type_server_script): |
Owner
There was a problem hiding this comment.
this is already tested above or maybe we could just add one assert above with the case name=None?
| assert "Name: None" in result_with_null | ||
|
|
||
|
|
||
| def test_json_schema_inspection(json_schema_array_type_server_script): |
Owner
There was a problem hiding this comment.
I don't think we need those tests for now I prefer to focus on "E2E" tests from the MCP with somewhat real use scenario to avoid growing the code base / test bases unnecessarly
| print(f"Error during schema inspection: {e}", file=sys.stderr) | ||
|
|
||
|
|
||
| def test_direct_modeling_with_list_type(): |
Owner
There was a problem hiding this comment.
this test could be nice but I would remove the verbose try / except explaining the type error and just keep it to the essential
Contributor
Author
|
Sorry for the delay, I will address your comments and upload a new version soon. |
…ling
- Extended JSON Schema array notation fix to langchain_adapter.py
- Added support for both array notation ("type": ["string", "number"])
and anyOf structures in LangChain adapter
- Reorganized tests per reviewer feedback:
* Moved simplified direct test to tests/utils/test_modeling.py
* Added E2E test to test_langchain_adapter.py
* Removed redundant test file
This commit ensures consistent handling of JSON Schema list-type fields
across all adapters and addresses all feedback from the PR review.
Contributor
Author
|
Thank you for your feedback on the PR. I've implemented your suggested changes and also found that the same JSON Schema array notation issue needed fixing in the langchain_adapter.py file as well. Changes made:
The tests now pass and demonstrate that our fix properly handles JSON Schema array notation in both modules. Let me know if you'd like any additional changes! |
Owner
Thanks for the change I will have a look asap! |
grll
approved these changes
Jun 1, 2025
grll
left a comment
Owner
There was a problem hiding this comment.
looking good thanks for the change and the contribution!
amithkk
pushed a commit
to amithkk/mcpadapt
that referenced
this pull request
Sep 6, 2025
…l#37) * fix: Add support for list-type JSON Schema fields in modeling.py Problem: - JSON Schema allows specifying multiple types using array notation: {"type": ["string", "number"]} - This is valid per JSON Schema specification, and common in real-world schemas - The mcpadapt modeling.py module failed with "unhashable type: 'list'" when processing such schemas - Error occurs in get_field_type() when attempting to use a list as a dictionary key Solution: - Enhanced get_field_type() to properly handle list-type JSON Schema types - Added special case to detect when json_type is a list - Implemented conversion of list-type to Python Union types - For single-item lists, extract and use the single type - For multi-item lists, create a Union of all mapped types - Preserves original behavior for all other schema types This fix ensures compatibility with JSON Schema that use the array notation for specifying multiple allowed types for a field, which is a common pattern in the JSON Schema ecosystem. The fix is backwards compatible and follows the expected behavior of properly converting JSON Schema types to their Python equivalents. * test: Add dedicated test for JSON Schema list-type handling This commit adds a comprehensive test suite for validating the fix for JSON Schema array notation in type fields (e.g., "type": ["string", "number"]). Key additions: - New test file tests/test_modeling.py with multiple test scenarios: - Direct test against modeling.py to verify handling of list-type JSON Schema fields - Tests for array-type fields with multiple primitive types - Specific tests for handling of null types in array notation - Inspection utility to examine actual schema structure in MCP tools The tests are designed to: 1. Verify the fix works correctly for all edge cases 2. Provide clear diagnostics when the bug is present 3. Demonstrate proper handling of various JSON Schema type patterns 4. Ensure consistent behavior with the existing anyOf implementation The test handles both the "happy path" (with fix) and failure path (without fix), making it valuable for preventing regressions. It also improves null type handling to be consistent with how the codebase already handles nulls in anyOf constructs. This testing approach validates that our implementation correctly supports the JSON Schema specification, which allows multiple types to be specified either via array notation or anyOf constructs. * fix: Address PR grll#37 review feedback on JSON Schema list-type handling - Extended JSON Schema array notation fix to langchain_adapter.py - Added support for both array notation ("type": ["string", "number"]) and anyOf structures in LangChain adapter - Reorganized tests per reviewer feedback: * Moved simplified direct test to tests/utils/test_modeling.py * Added E2E test to test_langchain_adapter.py * Removed redundant test file This commit ensures consistent handling of JSON Schema list-type fields across all adapters and addresses all feedback from the PR review. --------- Co-authored-by: Sakthi Kannan <saktr@amazon.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem:
Solution:
This fix ensures compatibility with JSON Schema that use the array notation for specifying multiple allowed types for a field, which is a common pattern in the JSON Schema ecosystem. The fix is backwards compatible and follows the expected behavior of properly converting JSON Schema types to their Python equivalents.