Dify Community Proposes Structured Output Fix After Reasoning-Block JSON Is Mistaken for the Final Answer

Dify’s structured output flow has a parsing issue that workflow developers should be aware of. On October 13, a user reported that a self-hosted Dify 1.11.2 Enterprise instance calling a reasoning model through LiteLLM and vLLM returned {"think":"start"} from the reasoning text as structured_output, even though the final answer contained the requested type and content fields. The report included configuration, streaming fields, and output comparisons; the issue was still observed after reasoning tag separation was enabled. Original report

The technical focus is the order of parsing. The report’s analysis says a provider plugin may first wrap reasoning content in <think> tags, then combine it with the answer. The structured parser receives the full text and, after direct parsing fails, passes it to json_repair. If the result contains multiple objects, the existing path selects the first dictionary, so it may pick up a temporary object from the reasoning block. Another participant ran a focused test against a function on the then-current main branch and got the same result on both blocking and streaming paths. However, the test used simulated model inputs and outputs and did not validate a full deployment. Technical discussion

A fix proposed the same day in PR #44005 skips an initial reasoning block in a specific repair path before parsing the answer that follows. The proposal preserves the original message and streaming chunks to avoid rewriting legitimate <think> text inside the answer string. The author also listed tests for tags split across chunks, case variants, and plain JSON. However, the existing behavior remains for truncated or reasoning-only content, and full Schema validation is not included; these edge cases still need review. Fix proposal

The official documentation describes structured output as data for programmatic use and explains that reasoning separation can move thinking content into a separate variable. This makes the case practically relevant: based on the scenario above, if downstream nodes use the parsed result directly, classification, field extraction, or conditional branching could receive the wrong object. Engineering teams should add a validation case where reasoning and answer content each contain different JSON, and check required fields. As of this report, the proposal is still open; it should not be considered an official fix, nor can it be assumed that all models and versions are affected. Official LLM node documentation