Dify Proposes ReAct Parsing Fix to Prevent Braces in Strings from Skipping Tool Calls

On November 6, the Dify community submitted PR #45741, proposing a fix for parsing streamed output from ReAct agents. The issue report reproduced the problem directly on the main branch at the time: even when the model generated a valid tool instruction, the parser could truncate it if a parameter string contained braces. This could cause the executor to skip the tool call and send the raw JSON to the user as the answer. Reproducing the issue requires only feeding in model output text; it does not depend on a particular provider. Issue report

For example, if a search parameter contains close } brace, the old logic also counted the closing brace inside the string toward the structural depth and could prematurely conclude that the instruction had ended. An unmatched opening brace inside a string could instead cause the following answer to be absorbed into the payload. Another failure path occurs when ordinary text before an instruction contains a closing brace: it can contaminate the cache and prevent the next valid instruction from being parsed. These cases may not produce a clear error message, making it harder to diagnose agents that fail to execute tools. Reproduction and execution path

The JSON specification allows braces inside strings. To determine object boundaries, a parser must distinguish string contents, quotation marks, and escape characters. Therefore, valid parameters like these cannot be segmented through brace counting alone. RFC 8259 string rules

The proposal replaces the original counter with a combination of structural depth, string state, and escape state. It updates depth only outside strings and adjusts cache handling after a payload is complete. The author reports that all five newly added cases failed before the change and that all 70 tests passed afterward, including existing cases covering escaped quotes, nested inputs, and stray braces. This is still limited validation reported by the author. Fix and tests

For engineering teams, this is a reminder that agent reliability also depends on the parsing layer between model output and tool execution. Based on the failure mechanism described above, validation should compare the raw output, the parsed action, and the actual tool logs. Follow-up should track review, merge, and release inclusion. The proposal also explicitly leaves other malformed action formats unaddressed, so its impact should not be generalized to all agent paths. Proposal status and scope