[Bug] ChatAdapter cannot parse response without newlines correctly

[FireMasterK]

trafficstars

What happened?

When using the Gemini 2.5 pro model, the response sometimes doesn't adhere to the specific newline requirements for parsing the correctly.

Error log:

Adapter ChatAdapter failed to parse the LM response. 

LM Response: [[ ## next_thought ## ]]
The user wants me to ...snip...transactions.[[ ## next_tool_name ## ]]
redacted[[ ## next_tool_args ## ]]
{
    "query": "redacted"
}
[[ ## completed ## ]] 

Expected to find output fields in the LM response: [next_thought, next_tool_name, next_tool_args] 

Actual output fields parsed from the LM response: [next_thought] 

To fix this, I propose parsing this without involving newlines to both simplify logic, and prevent this kind of parsing errors like in #8374.

Alternatively, maybe the prompt could also be optimized to be more specific about the formatting?

Steps to reproduce

Since it's a model hallucination (as it doesn't include the newline correctly), it doesn't happen consistently.

I was using an agent with dspy.ReAct and tools is how I got this error. It doesn't happen all the time, but rarely on some queries.

DSPy version

2.6.27

[chenmoneygithub]

@FireMasterK Thanks for opening the issue report! We actually realized that reasoning model sometimes don't follow the structural requirement, like newline or so. To use a reasoning model, please use the TwoStepAdapter: https://dspy.ai/api/adapters/TwoStepAdapter/

Basically we use a second LM call to parse the response into the output field as defined in the signature.

[FireMasterK]

@FireMasterK Thanks for opening the issue report! We actually realized that reasoning model sometimes don't follow the structural requirement, like newline or so. To use a reasoning model, please use the TwoStepAdapter: https://dspy.ai/api/adapters/TwoStepAdapter/

Basically we use a second LM call to parse the response into the output field as defined in the signature.

This is great, but sometimes I've had this issue happen in certain non-reasoning models too. Would it be a good idea to update the prompt slightly to instruct it to be specific about the newlines?

I'd be happy to make another PR if you think it's a reasonable idea.

[IliaMManolov]

Hi there, we are facing the same issue and doing two LLM calls is not ideal. We would rather either see a more graceful handling of misformatted output like this (maybe the option to retry) or, more simply, a more lax parsing of the LLM output as @FireMasterK proposed. As it is currently, when this fails (and it always fails on our end for some tools) this throws us all the way to dspy.ReAct.acall and we have no way of recovering (i.e. telling the LLM to correct itself).

[chenmoneygithub]

@IliaMManolov Have you tried JSONAdapter or XMLAdapter? A relaxed handling is risky because it means we are adding arbitrary assumption in order to reconstruct the desired format.