@tmchowchecks…fix/3145-filehelper-anyof-schema → next1 files · +30 −15review: @haxziereview: @jkomynoupdated 1mo agoSchemas using anyOf/oneOf/allOf without a top-level "type" key were silently skipped during recursive file upload/download processing in FileHelper. This meant nested objects or arrays wrapped in combiners never got their file_uploadable/file_downloadable properties processed.
Fixes #3145
_resolve_object_schema helper that returns the first {"type": "object"} variant from anyOf/oneOf/allOf, or the schema itself if it already has "type": "object"_resolve_array_schema helper with the same pattern for arrays_substitute_file_uploads_recursively to use these helpers for nested object and array handling_substitute_file_downloads_recursively with the same fixTraced through the code paths manually with the MRE schema from the issue:
{
"anyOf": [
{"type": "object", "properties": {"x": {"type": "string"}}},
{"type": "null"}
]
}
Before: _resolve_object_schema did not exist. param_schema.get("type") returned None for this schema, skipping recursion entirely.
After: _resolve_object_schema finds the {"type": "object"} variant and returns it. The recursive function processes nested properties correctly.
The KeyError: 'type' mentioned in the issue title has already been mitigated in the current next branch code (uses .get("type") instead of ["type"]). This PR fixes the remaining functional gap where schemas without a top-level type were silently skipped rather than being resolved through their combiner variants.
The two new helpers follow the same iteration pattern as the existing _find_uploadable_schema_variant method (lines 667-687).
@tmchow is attempting to deploy a commit to the Composio Team on Vercel.
A member of the Team first needs to authorize it.
