Open agrigeorge opened 1 month ago
Hey @agrigeorge! I'm here to help you out with any bugs, questions, or contributions you have for the project. Let's work together to tackle this issue!
To resolve the issue where the inputs
field in your OpenAPI specification is being interpreted as a string instead of an object in Dify, ensure that the type
of the inputs
field is correctly specified in the OpenAPI schema. The ApiBasedToolSchemaParser
class uses the _get_tool_parameter_type
method to determine the type of parameters.
Here's a snippet from the code that shows how the type is determined:
@staticmethod
def _get_tool_parameter_type(parameter: dict) -> ToolParameter.ToolParameterType:
parameter = parameter or {}
typ = None
if 'type' in parameter:
typ = parameter['type']
elif 'schema' in parameter and 'type' in parameter['schema']:
typ = parameter['schema']['type']
if typ == 'integer' or typ == 'number':
return ToolParameter.ToolParameterType.NUMBER
elif typ == 'boolean':
return ToolParameter.ToolParameterType.BOOLEAN
elif typ == 'string':
return ToolParameter.ToolParameterType.STRING
elif typ == 'object':
return ToolParameter.ToolParameterType.OBJECT
To ensure that the inputs
field is interpreted as an object, define it in your OpenAPI specification with the type
set to object
. Here is an example:
components:
schemas:
YourSchema:
type: object
properties:
inputs:
type: object
properties:
query:
type: string
By specifying the type
as object
for the inputs
field, the parser will correctly interpret it as an object instead of a string [1].
Additionally, there is a known limitation in the current version (v0.6.8) of Dify that affects the interpretation of nested object types within the OpenAPI schema. The ApiBasedToolSchemaParser
class does not handle nested object types [1].
To continue the conversation, mention @dosu.
Self Checks
Dify version
0.6.8
Cloud or Self Hosted
Cloud
Steps to reproduce
Define an OpenAPI specification for the tool with an inputs field designated as an object. Add this specification as a tool to an agent in dify.ai. Observe that the input is interpreted as a string rather than an object.
✔️ Expected Behavior
The inputs field defined in the OpenAPI specification should be interpreted as an object, enabling the correct configuration and data exchange between tools in the workflow.
❌ Actual Behavior
The inputs field is incorrectly interpreted as a string, which disrupts the proper integration and functionality of the tool within the workflow.
Additional Context
I am aware that currently, dify.ai does not support chaining multiple agents together or allowing agents direct access to workflows, though it appears this functionality may be planned for future implementation. In light of this limitation, I have opted to use a workaround by integrating individual agents via an OpenAPI specification, treating them as tools within each agent.
To manage the integration, I constructed an OpenAPI specification and incorporated it as a tool for each agent. The workflow configuration requires the inputs field to be structured as an object. However, there is an ongoing issue where dify.ai interprets these object fields as strings. This problem was previously reported in multiple issues and was considered resolved. Despite this, my implementation is still encountering this interpretation error.
Thank you for your time and help with this issue. Please let me know if there's anything I might be missing or any additional steps I should consider to resolve this problem. Your assistance is greatly appreciated!
related issues: https://github.com/langgenius/dify/issues/3421 https://github.com/langgenius/dify/issues/3796 https://github.com/langgenius/dify/issues/2315