New custom tool: invalid schema: unhashable type: 'list'

[JMLX42]

Self Checks

• [X] This is only for bug report, if you would like to ask a question, please head to Discussions.
• [X] I have searched for existing issues search for existing issues, including closed ones.
• [X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• [X] Please do not modify this template :) and fill in all the required fields.

Dify version

0.15.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

1. Create a new custom tool
2. Copy/paste the following OpenAPI definition: glTF.json

That OpenAPI definition is valid according to the official OpenAPI validation tool (openapitools/openapi-generator-cli validate).

✔️ Expected Behavior

No error.

❌ Actual Behavior

A popup error on the top right corner with the following message:

invalid schema: invalid schema: unhashable type: 'list'

[dosubot[bot]]

Hello, @JMLX42! I'm here to help you with any bugs, questions, or contributions while you're waiting for a human maintainer. Let's tackle this together!

The error message "unhashable type: 'list'" typically occurs in Python when a list is used in a context that requires a hashable type, such as a key in a dictionary or an element in a set. In the context of Dify, this error might be related to how the OpenAPI definition is being processed or parsed.

To address this issue, you can check the following:

1. OpenAPI Definition Structure: Ensure that the OpenAPI definition does not contain lists where a dictionary or a set is expected. This might involve checking the structure of the JSON file to ensure it adheres to the expected schema format.

2. Parsing Logic: The error might be occurring in the parsing logic within Dify. The ApiBasedToolSchemaParser class in the api/core/tools/utils/parser.py file is responsible for handling and parsing OpenAPI definitions. You might want to review this part of the code to see if lists are being used inappropriately in hashable contexts ^[1].

3. Validation: Although the OpenAPI definition is valid according to the official OpenAPI validation tool, there might be specific requirements or constraints in Dify's implementation that are not covered by the general validation. Double-check any custom validation logic that might be present in the codebase.

By focusing on these areas, you may be able to identify and resolve the issue causing the "unhashable type: 'list'" error.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[JMLX42]

OpenAPI Definition Structure: Ensure that the OpenAPI definition does not contain lists where a dictionary or a set is expected. This might involve checking the structure of the JSON file to ensure it adheres to the expected schema format.

@dosu I don't think it can happen if the OpenAPI definition is checked valid. Correct?

Parsing Logic: The error might be occurring in the parsing logic within Dify. The ApiBasedToolSchemaParser class in the api/core/tools/utils/parser.py file is responsible for handling and parsing OpenAPI definitions. You might want to review this part of the code to see if lists are being used inappropriately in hashable contexts [1].

@dosu anyway to get the exact line where the error happens?

[dosubot[bot]]

If the OpenAPI definition is valid according to the official OpenAPI validation tool, it should generally adhere to the expected schema format. However, Dify might have additional constraints or specific parsing logic that could lead to issues not covered by standard validation.

To pinpoint the exact line where the error occurs, you can enable or review the logging and error handling mechanisms in the ApiBasedToolSchemaParser class. This class includes several error handling mechanisms that capture and log parsing errors, which might help identify the source of the issue. For example, it raises specific exceptions like ToolApiSchemaError and logs warnings for non-critical issues ^[1]. You might want to check the logs generated by these mechanisms to find more detailed information about the error.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[tipani86]

I second. Something seem to be wrong in the custom tool request generation and list types with v. 0.15.1.

I had earlier version work with list[dict] form and although Dify now claims the request it generates is still valid (in the runtime tracing input), what I see from the API server response is type check error.

However, when I copy what Dify claims to have sent and send it manually via cURL or postman or even the FastAPI's own docs page, the request does go through.

So I suspect something in 0.15.1 (or possibly 0.15.0) changed so that what is shown to be sent and what is actually sent aren't the same.

For the record, my test request format looks like this:

{
  "username": "Tianyi",
  "lesson_set": "HSK2",
  "lesson_name": "HSK2 Lesson 1 I like the weather in October",
  "passed": true,
  "vocabulary": [
    {
      "name": "因为",
      "leitner_box": 2
    },
    {
      "name": "阴天",
      "leitner_box": 2
    },
    {
      "name": "阴",
      "leitner_box": 2
    },
    {
      "name": "早",
      "leitner_box": 2
    },
    {
      "name": "长",
      "leitner_box": 2
    }
  ]
}

As you can see, it is the vocabulary part that is the problem as it's a list of dicts (or objects)

Reproduction steps:

When it's sent manually, it works:

And here is same request format in Dify, failing:

[a-taka]

I'm facing the similar issue that type check returns error without calling the api:

It worked before with the following a item of openapi spec:

funcList:
  type: array
     items:
        type: object
           properties:
              name:
                type: string
              difficulty:
                type: string

But the tool is failing to call this api: "tool invoke error: Request failed with status code 400 and {\"message\":[\"each value in nested property funcList must be either object or array\"],\"error\":\"Bad Request\",\"statusCode\":400}"

The actual value to this api was correct and the exact same as the value it worked before. There is no type error in the value.

[dosubot[bot]]

Hi, @JMLX42. I'm Dosu, and I'm helping the Dify team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• Bug in Dify version 0.15.1 when creating a custom tool with a valid OpenAPI definition.
• Error message: "invalid schema: unhashable type: 'list'".
• Suggested cause: Issue in ApiBasedToolSchemaParser class related to schema processing.
• Similar issues reported by @tipani86 and @a-taka, indicating a potential problem with list type handling.
• Manual requests succeed, but fail within Dify, suggesting a discrepancy in request handling.

Next Steps:

• Please confirm if this issue is still relevant to the latest version of Dify.
• If no response is received, the issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

[a-taka]

Hi, @JMLX42. I'm Dosu, and I'm helping the Dify team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• Bug in Dify version 0.15.1 when creating a custom tool with a valid OpenAPI definition.
• Error message: "invalid schema: unhashable type: 'list'".
• Suggested cause: Issue in ApiBasedToolSchemaParser class related to schema processing.
• Similar issues reported by @tipani86 and @a-taka, indicating a potential problem with list type handling.
• Manual requests succeed, but fail within Dify, suggesting a discrepancy in request handling.

Next Steps:

• Please confirm if this issue is still relevant to the latest version of Dify.
• If no response is received, the issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

I could not find any fix at the latest version: main. It still fails.

[tipani86]

I temporarily worked around by changing my own API behavior and input format to accommodate this change/bug but of course that is just a really bad hack and you cannot do that with third-party APIs which you have no control over. But yeah, it's bad that it seems it's still sending broken requests although the UI printout seems to be OK.

[JMLX42]

@tipani86 can you please explain the exact changes to made to your API definition to work around this?

[tipani86]

@tipani86 can you please explain the exact changes to made to your API definition to work around this?

So the original issue on my end is Dify's tool call might not be able to format a valid list of objects (with the caveat being it used to but after 0.15-ish the error started).

I think what I did was I changed the OpenAPI definition and re-format that part as if it's stringified JSON, and I'd parse it myself on the server end back to lists and objects.

Again, this is only possible if I can change the behavior logic of my API endpoint to accommodate the issue at request formation. Doesn't work if it's a third party API with a request format which cannot be changed.

[dosubot[bot]]

Hi, @JMLX42. I'm Dosu, and I'm helping the Dify team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• You reported a bug in Dify version 0.15.1 when self-hosted via Docker, causing an "unhashable type: 'list'" error with custom tools.
• I suggested reviewing the OpenAPI definition and ApiBasedToolSchemaParser class.
• Other users, including tipani86 and a-taka, confirmed similar issues, indicating a potential internal processing problem.
• Tipani86 found a temporary workaround by altering API input format, but it's not viable for third-party APIs.
• The issue remains unresolved in the latest version, as confirmed by a-taka.

Next Steps:

• Please let us know if this issue is still relevant to the latest version of the Dify repository by commenting here.
• If there is no further activity, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!