-
Notifications
You must be signed in to change notification settings - Fork 47
fix: Add support for list-type JSON Schema fields in modeling.py #37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
|
Hey @sakthikannan25 thanks for the PR I will review soon! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
tests/test_modeling.py
Outdated
| assert "Name: None" in result_null | ||
|
|
||
|
|
||
| def test_json_schema_array_type_with_null(json_schema_array_type_server_script): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is already tested above or maybe we could just add one assert above with the case name=None?
tests/test_modeling.py
Outdated
| assert "Name: None" in result_with_null | ||
|
|
||
|
|
||
| def test_json_schema_inspection(json_schema_array_type_server_script): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
tests/test_modeling.py
Outdated
| print(f"Error during schema inspection: {e}", file=sys.stderr) | ||
|
|
||
|
|
||
| def test_direct_modeling_with_list_type(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this test could be nice but I would remove the verbose try / except explaining the type error and just keep it to the essential
|
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.
|
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! |
Thanks for the change I will have a look asap! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking good thanks for the change and the contribution!
…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 <[email protected]>
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.