The dify process executed without any errors, but the API did not return a value（dify流程执行没有报错，但是API没有返回值）

Discussion
6

The supplementary information is crucial, thank you!

Let’s summarize the key information first:

  • Dify Version: 1.11.0
  • Workflow Structure: Multi-path LLM → Code Execution 3 → “Direct Reply”
  • Direct Reply Node Configuration: Simply references {{ Code Execution 3.result }}
  • You confirm: The result of Code Execution 3 is always a normal, parsable JSON string (in Markdown format)
  • When abnormal: The HTTP interface completely returns nothing, as if the request is hanging / timing out, with no response body received.

With these points combined, the problem is no longer “the answer field is sometimes empty,” but rather:

The workflow completes internally, but occasionally freezes/fails when writing the “Direct Reply” result back to the HTTP response (possibly a backend bug or specific content triggering an exception), causing the client to receive no HTTP response.

Below, I’ll explain by “suspected cause + suggested troubleshooting/mitigation methods,” which you can try step by step:

1. First, rule out: Is the request still running, and you just haven’t waited long enough?

In 1.11.0, if a Workflow has many nodes and all are calling LLMs in series/parallel, an execution can sometimes take several minutes. Please confirm two points:

  1. For those requests that “have no return”:

    • Does the workflow log immediately show that the “Direct Reply” node has executed successfully?
    • Or does the log also wait a long time before “Direct Reply” turns green :white_check_mark:?

  2. On the client side:

    • Have you set a timeout yourself (e.g., HTTP client 30-second timeout)?
      If so, you might have actively disconnected the request before the server returned, which would also appear as “no return at all” locally.

Suggested quick test:

  • Use Postman / curl to send the same API request, and set the HTTP client timeout longer (e.g., 300 seconds):
    • If Postman eventually gets a result, but your code doesn’t, it’s likely a timeout setting issue in your code;
    • If Postman also keeps hanging without returning, then Dify is truly “not writing back a response.”

2. Check the “Session Log Details” for the failed attempt for any exception stack traces.

Although you said “the workflow execution did not report an error,” there are two situations that need special attention:

  1. Entire execution log:
    Open the “Details” / “Trace” in the upper right corner of the “Conversation Log” and check the very bottom for small red markers like “System Error” or “Internal Error.”

  2. Direct Reply node internal log:

    • Click on the “Direct Reply” node and see if there are “Rendering failed” or “Template error” prompts;
    • For example: variable not found, Jinja template error, etc. Sometimes the UI only shows a yellow/red small icon, which may not be obvious.

If you see error messages in these places, you can paste them (be sure to anonymize), and I can help you translate them into specific causes.

3. Perform a small modification test for “result is a JSON string.”

Because you said result is “a Markdown-formatted JSON string,” we need to rule out two things:

  1. Whether there are Markdown symbols before and after the JSON (e.g., json code block, backticks, prefix text, etc.). It looks “formattable” in the conversation log, but the backend might have extra logic when processing/recording;
  2. Certain special characters (control characters, extremely long single lines, special Unicode) occasionally trigger serialization exceptions.

I suggest you make a minimal change first:

In Code Execution 3, change the return to be a real object, not a “JSON string”:

import json

# Assuming your current result is a string json_str
data = json.loads(json_str)   # First convert to a Python object

return {
    "safe_result": data
}

Then change the “Direct Reply” node to:

{{ nodes["代码执行 3"].outputs.safe_result | tojson }}

Or simply output a fixed text:

Debug: OK

Test in two steps:

  1. Only output fixed text Debug: OK:
    • If there are no more “no return” situations at this point, it means the problem is highly concentrated on “the content of that JSON string itself”;
  2. Then change to output the object using | tojson:
    • If it’s also stable, it means the previous method of “directly using Markdown JSON strings” might trigger some serialization/encoding exception in extreme cases.

4. See if it’s an “Asynchronous Trigger / Webhook” type of issue.

You previously said “the HTTP response with no return, is directly no return, no return interface was called.” I want to confirm whether you are using:

  • Standard synchronous interface (e.g., /v1/workflows/trigger, /v1/chat-messages, expecting an answer to be returned immediately);
  • Or are you using “asynchronous mode” (e.g., configured Webhook, polling results, etc.), in which case the normal behavior is that the initial call does not directly include the result.

If you are unsure, you can paste the URL you are calling, such as:

POST /v1/workflows/trigger

Or:

POST /v1/workflows/events

Such paths (without domain, token), and I will help you determine.

5. Combining with the status of 1.11.0: It is recommended to add an extra layer of “protection” + “logging.”

The current phenomenon seems to be:

  • Most of the time everything is normal;
  • Occasionally, “a certain input + certain JSON content” causes an internal exception (or timeout) when writing back the response, the UI only shows the node executed successfully, but the HTTP channel hangs.

Before you can immediately upgrade / troubleshoot the source code, you can first use “defensive coding” to try to avoid triggering edge cases:

  1. In Code Execution 3, perform a fallback process for the result that will eventually be returned:

    import json
from datetime import datetime

def safe_result(raw):
    try:
        # If it's already a dict, return directly
        if isinstance(raw, dict):
            return raw
        # If it's a string, try to parse
        if isinstance(raw, str):
            return json.loads(raw)
    except Exception as e:
        return {
            "error": "json_parse_failed",
            "message": str(e),
            "raw": raw,
            "time": datetime.utcnow().isoformat()
        }
    # Other types are wrapped directly
    return {
        "wrapped": raw,
        "time": datetime.utcnow().isoformat()
    }

# Your original generated json string is called raw_json
return {
    "result": safe_result(raw_json)
}

  2. In the “Direct Reply” node, uniformly use:

    {{ nodes["代码执行 3"].outputs.result | tojson }}

The advantage of doing this is:

  • Even if strange content is encountered, at most you will get a JSON containing error: json_parse_failed, instead of the entire HTTP request having no return.

6. If convenient, please provide two more pieces of information.

To further determine whether it’s a “content issue” or a “backend bug,” you can later supplement:

  1. A complete HTTP response (after anonymization) from a “normal return,” and the corresponding answer text from the “Direct Reply” node for that instance;
  2. A “conversation log screenshot” (from start to the direct reply node, confirming all nodes are green checkmarks) for an instance where there was “no return,” especially the content displayed inside the direct reply node.

Based on these two sets of comparisons, I can determine:

  • Whether it’s an issue caused by specific size (particularly long JSON);
  • Whether it contains special characters / Emoji / control characters;
  • Whether there’s a clear pattern (e.g., only hangs when certain LLM branches generate specific content).

Summary of current suggested operation order

  1. Use Postman/curl to directly call the API, extend the timeout, and confirm whether Dify truly isn’t responding or if the client is timing out.
  2. Modify the “Direct Reply” node to first output fixed text, and see if “empty HTTP returns” still occur.
  3. Change the JSON to “object + tojson output” to avoid directly passing Markdown JSON strings.
  4. Add safety wrappers and error information in the code node to prevent internal exceptions due to extreme JSON content.
  5. If the problem disappears after steps 2 and 3, you might consider this a content-related bug in 1.11.0. It is recommended to upgrade to a higher version if conditions permit, or report this issue to GitHub with a reproducible example.

If you are willing, you can try step 2 first: change “Direct Reply” to fixed text, and see if “completely no return” still occurs in the next few dozen calls; then we can analyze further together once you have results.