[BUG]

[lyjxxxx]

Problem (one or two sentences)

when calling tool ask_followup_question, some models output followup in string format. However, it requires array format. I hope this function calling can support string format of followup

Context (who is affected and when)

whenever calling ask_followup_question tool

Reproduction steps

Mac OS. using Qwen3.6 35B-A3B JANGTQ4 to call ask_followup_question. It shows that followup parameter is missing

Expected result

the model can call ask_followup_question properly

Actual result

it fails to call ask_followup_question because the followup is in string format, yet array format is required

Variations tried (optional)

No response

App Version

3.53.0

API Provider (optional)

OpenAI Compatible

Model Used (optional)

Qwen3.6 35B-A3B JANGTQ

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Problem: When smaller models (like Qwen3.6 35B-A3B) call ask_followup_question, they sometimes output follow_up as a string instead of the required array format. This causes the tool call to fail with a missing parameter error.

Root Cause: Three locations enforce array-only follow_up:

1. src/core/tools/AskFollowupQuestionTool.ts (line 37) - rejects non-array with !Array.isArray(follow_up)
2. src/core/assistant-message/NativeToolCallParser.ts (line 480) - partial streaming drops non-array values
3. src/core/assistant-message/NativeToolCallParser.ts (line 825) - finalization passes raw value without coercion

Proposed Fix:

1. Add a coercion helper in AskFollowupQuestionTool.ts that normalizes follow_up from various string formats into the expected array:

   • If follow_up is already an array, use it as-is
   • If it's a JSON string that parses to an array, parse and use it
   • If it's a plain string, wrap it as [{ text: follow_up, mode: null }] (single suggestion)

2. Update NativeToolCallParser.ts in both the partial (createPartialToolUse, ~line 480) and finalization (finalizeStreamingToolCall, ~line 822) handlers to apply the same coercion, so string values are normalized to arrays before they reach the tool.

3. Add/update tests in src/core/tools/__tests__/askFollowupQuestionTool.spec.ts to cover:

   • follow_up as a JSON string of an array (e.g., "[{\"text\": \"option 1\"}]")
   • follow_up as a plain string (e.g., "option 1\noption 2")
   • Existing array behavior remains unchanged

This approach is backwards-compatible -- models that already produce arrays won't be affected, and models that produce strings will now have their output gracefully coerced.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[lyjxxxx]

@roomote I approve this plan

[roomote-v0]

Thanks for the approval! I've seen your comment and will now proceed with the implementation. I'll open a PR to share progress shortly.

[roomote-v0]

Opened PR #12234 with my attempt at addressing this. The fix adds coercion logic so that string-format follow_up values are automatically normalized to the expected array format. All tests pass. Feedback welcome!

[lyjxxxx]

@roomote After I adopt this change, models can call ask_followup_question tool correctly. However, when I choose an answer, my model gives an error: Chat template error: Runtime error: Cannot convert value of type Optional to Jinja Value

[roomote-v0]

I've seen your comment about the Jinja template error when selecting a follow-up answer. The error "Cannot convert value of type Optional to Jinja Value" likely comes from null/undefined values in the tool response being sent back to the model. I'll investigate and open a PR with a fix.

[roomote-v0]

Opened PR #12236 with my attempt at addressing the Jinja template error. The fix makes the mode field optional in the tool schema (preventing models from outputting "mode": null) and strips null values from tool call arguments during serialization as a safety net. Feedback welcome!