“Tokens maximum recursion depth exceeded while calling a Python object”

[Jas0nxlee]

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.10.0beta3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

[dosubot[bot]]

The "maximum recursion depth exceeded while calling a Python object" error in your self-hosted Dify setup could be related to the _transform_result method in the CodeNode class. This method processes nested dictionaries, and if the depth exceeds the configured maximum (dify_config.CODE_MAX_DEPTH), it can lead to a recursion depth error. The default maximum depth is set to 5 ^[1][2].

To address this, you might want to check if the data being processed has a nesting level that exceeds this limit. If necessary, you can adjust the CODE_MAX_DEPTH configuration to accommodate deeper structures, or refactor the data to reduce its depth.

To continue talking to Dosu, mention @dosu.

[kkjinping]

I find that only when the variable is set to the Context will this problem occur. Setting the variable directly to the SYSTEM will not.

[fniu]

Came across the same issue. Any progress on this? Thanks!

[leoterry-ulrica]

also encountering the same issue

[SimonUTD]

it seems because the file is tooo big and the content is toooo long. i upload a 1.5mb txt file and get the same issue, but after i shorter the file, it works

[fniu]

it seems because the file is tooo big and the content is toooo long. i upload a 1.5mb txt file and get the same issue, but after i shorter the file, it works

I don't think this is the reason. It fails for me with normal size context. FYI, I am using the Cloud service.

This issue is getting quite annoying. Could you please prioritize this issue? Thanks @crazywoola or someone else I should ping.

[fniu]

After some debugging, I suspect that this has something to do with the content of the retrived trunks. When there are long sequences of dots, such as "............." (also present in the screenshot by the original author of this issue), LLMs tend to fail with this error. Hope this helps.

Edit: I am pretty sure the sequences of dots are the cause of the error (at least for me). I disabled all the trunks that contains dots, and the error is gone. Whenever the error shows up, at least one retrieved trunk contains dots.

[ip2cloud]

Hi.. it's still running even in version 0.10.0 of 10/21/24