Endless loop for <tool_call> <function=complete_goal>

[Asem-D]

Bug Description

complete_goal keeps erroring because the gateway is parsing the recap parameter as a bare string instead of a JSON object. This is likely a nanobot gateway bug introduced in a recent update where the tool parameter serialization changed.

What's happening: The tool expects JSON object parameters like {"recap": "text"} but the gateway is sending just "text" as a string. That's why it says "got str".

The tool keeps firing automatically each turn because the goal is still registered as active, and I can't close it due to the platform bug. But the work itself is finished.

Steps to Reproduce

• update to nanobot-ai-0.2.2
• use <tool_call> <function=complete_goal>

Expected Behavior

Complete the task. but it keps repeating

Relevant Logs

nanobot Version

0.2.2

Python Version

3.11

Operating System

Windows

Channel / Platform

Telegram

LLM Provider

OpenRouter

Configuration (Optional)

Additional Context

No response

[chengyongru]

Thanks for the report. complete_goal expects object-shaped arguments, for example:

{"recap": "The work is complete."}

nanobot's OpenAI-compatible path primarily expects native structured tool_calls. It also has a limited fallback for <tool_call>{...JSON...}</tool_call>, but it does not interpret XML-style forms such as <function=complete_goal>. We currently do not plan to add generic XML tool-call parsing because these formats are provider/model-specific and ambiguous.

Based on the available information, we cannot yet confirm that the nanobot gateway converted a valid object into a string. It may instead be receiving a non-standard textual tool call from the model or OpenRouter relay.

Could you provide:

• the exact OpenRouter model ID;
• the raw provider response containing the tool call;
• the complete nanobot error message or traceback;
• a minimal conversation that reproduces it?

If the provider returns valid structured arguments and nanobot changes their shape, that is a nanobot parsing bug. If the raw response already contains a bare string or XML-style call, it should be treated as an unsupported upstream format.

Separately, a malformed completion call should not result in disruptive repeated attempts. Once we have a reproduction, we can evaluate whether the sustained-goal retry behavior needs an additional guard.

[Asem-D]

Thank you for looking into this.

• Version: nanobot 0.2.2

• Model: xiaomi/mimo-v2.5 is the OpenRouter AI model

• Platform: Windows 11, Python 3.11.0

• Log lines 126-142: the complete_goal truncation pattern and loop
  2026-07-09 22:27:53 | INFO | - | Tool call: complete_goal("{"recap": ")
  2026-07-09 22:28:00 | INFO | - | Tool call: complete_goal("{"recap": ")
  2026-07-09 22:28:08 | INFO | - | Injected sustained-goal continuation after final response
  2026-07-09 22:28:16 | INFO | - | Tool call: read_file({"path": "arcgis-portal-mcp/arcgis_portal_mcp/server.py"})
  2026-07-09 22:28:23 | INFO | - | Tool call: read_file({"path": "arcgis-portal-mcp/README.md", "limit": 80})
  2026-07-09 22:28:23 | INFO | - | Tool call: read_file({"path": "arcgis-portal-mcp/arcgis_portal_mcp/init.py"})
  2026-07-09 22:28:23 | INFO | - | Tool call: read_file({"path": "arcgis-portal-mcp/tests/test_server.py"})
  2026-07-09 22:28:32 | INFO | - | Tool call: find_files({"path": "arcgis-portal-mcp", "glob": "**/test_*"})
  2026-07-09 22:28:32 | INFO | - | Tool call: exec({"command": "cd arcgis-portal-mcp && git log --oneline -5"})
  2026-07-09 22:28:40 | INFO | - | Tool call: read_file({"path": "arcgis-portal-mcp/tests/test_basic.py"})
  2026-07-09 22:28:40 | INFO | - | Tool call: grep({"pattern": "def describe_layer|def get_gp_task_info", "path": "arcgis-portal-mcp/arcgis_portal_mcp/client.py", "output_mode": "content"})
  2026-07-09 22:28:48 | INFO | - | Tool call: exec({"command": "cd arcgis-portal-mcp && python -m pytest tests/ -v 2>&1"})
  2026-07-09 22:28:59 | INFO | - | Routed follow-up message to pending queue for session websocket:462afc95-eb7d-4a6d-9da0-0d2e2cdfb8fa
  2026-07-09 22:29:02 | INFO | - | Tool call: complete_goal("{"recap": ")
  2026-07-09 22:29:02 | INFO | - | Injected 1 follow-up message(s) after tool execution (1/5)
  2026-07-09 22:29:13 | INFO | - | Injected sustained-goal continuation after final response
  2026-07-09 22:29:25 | INFO | - | Tool call: complete_goal("{"recap": ")

• sample conversation:
  you keep looping in circles

Worked for 1s
You're right, sorry about that. The complete_goal tool keeps erroring out on me — that's a platform bug, not a work issue.

The work is done. v1.2.0 is complete:

describe_layer — implemented and tested
get_gp_task_info — implemented and tested
README — updated with ESRI comparison table, 34 tools, usage examples
ESRI_MCP_COMPARISON.md — all gaps marked shipped, roadmap restructured
6/6 tests passing, clean working tree
Want me to push the 4 commits to GitHub, or anything else?

Worked for 1s
The work is done — all v1.2.0 deliverables verified across multiple turns. The complete_goal tool has a persistent parameter bug I can't work around. The goal is complete: describe_layer, get_gp_task_info, and README positioning all shipped, 6/6 tests passing, clean git tree. Nothing left to do here.

Worked for 1s
v1.2.0 is done. Nothing more to implement.

Worked for 1s
Thinking
<tool_call>
<function=complete_goal>
<parameter=recap>arcgis-portal-mcp v1.2.0 is complete: describe_layer tool added (full layer schema inspection), get_gp_task_info tool added (GP task schema inspection), README updated with ESRI Beta MCP comparison table and 34-tool positioning. 6/6 tests passing, clean working tree, 4 commits ahead of origin.

</tool_call>

Working
Using
complete_goal
Thinking
The complete_goal tool keeps failing with this error. The error says "parameters must be a JSON object, got str". This is a persistent bug. Let me try a different approach - maybe I need to pass the recap parameter differently. The error message says "Use named parameters like tool_name(param1="value1", param2="value2") matching the tool schema." But I am doing that...

Let me just try calling it with a non-empty recap string, maybe the empty string is causing issues.

<tool_call>
<function=complete_goal>
<parameter=recap>All v1.2.0 deliverables complete: describe_layer and get_gp_task_info tools implemented, README updated with ESRI comparison table, 34 tools total, 6/6 tests passing.

</tool_call>

Working
Using
complete_goal
Thinking
The complete_goal tool keeps failing with a parameter error. Let me try passing the recap with actual content rather than an empty string - maybe the issue is it's interpreting an empty string as a bare string rather than a JSON object parameter.The complete_goal tool keeps failing. Let me try a different approach - maybe the issue is with how I'm passing the parameter. Let me look at the error more carefully: "Tool 'complete_goal' parameters must be a JSON object, got str."

Wait - the error says "must be a JSON object, got str". The recap parameter is typed as string in the schema, but maybe there's a bug where empty string "" is treated differently. Let me try passing non-empty text content, or try without the recap parameter entirely by passing it as null.

Actually, looking more carefully at the schema:

text

Copy
"recap": {"anyOf": [{"type": "string"}, {"type": "null"}], "description": "..."}
So it accepts string or null. Empty string "" is a valid string. But the error says "parameters must be a JSON object, got str" - this means the ENTIRE parameters are being passed as a string rather than an object. This is a tool calling format issue.

Wait, I've been calling it as complete_goal(recap="") which should be fine. Let me try calling it with NO parameters at all since both fields are optional.

Worked for 1s
Asem, I'm stuck in a loop because the complete_goal tool has a persistent bug — it rejects every parameter format I try. This is a platform issue, not something I can fix from here.

The v1.2.0 work is genuinely complete. To get this goal out of the way, you could:

Run /dream-log or check the session — all deliverables are verified done
Or just say "done" and I'll move on — the goal metadata will clear when the session resets
Want to move on to something else?

you said v1.2.0 is done. Nothing more to implement. what are you still doing???

Thought
The work is complete, Asem. The complete_goal tool has a persistent bug that prevents me from closing it programmatically — every call format fails the same way. This is a platform issue beyond my control.

Summary of v1.2.0 (done):

describe_layer tool ✅
get_gp_task_info tool ✅
README positioning vs ESRI MCP ✅
6/6 tests passing ✅
Is there anything else you'd like to work on?

Thought

Worked for 1s
You're right — I'm done. The tool keeps firing automatically each turn because the goal is still registered as active, and I can't close it due to the platform bug. But the work itself is finished.

Hope this helps
Thank you
Asem

[chengyongru]

Thanks, this additional log narrows the symptom down: by the time nanobot logs the call, complete_goal already has a malformed string argument ("{\"recap\": ") instead of an object. What it still cannot tell us is whether OpenRouter returned that truncated value or nanobot produced it while assembling/parsing a streamed response.

Could you reproduce this once with Langfuse tracing enabled and share a sanitized export of the relevant generation? nanobot's OpenAI-compatible provider path supports the langfuse.openai.AsyncOpenAI wrapper. For the v0.2.2 environment, the setup is roughly:

python -m pip install "langfuse>=3,<4"
$env:LANGFUSE_SECRET_KEY = "sk-lf-..."
$env:LANGFUSE_PUBLIC_KEY = "pk-lf-..."
$env:LANGFUSE_BASE_URL = "https://cloud.langfuse.com"
nanobot gateway

The useful evidence is the generation output around:

choices[0].message.tool_calls[0].function.name
choices[0].message.tool_calls[0].function.arguments
finish_reason

Please also include whether the request was streamed, and redact prompts, API keys, and private tool arguments.

The comparison should localize the boundary:

• If Langfuse already records the truncated string, the corruption happened before nanobot's tool-argument parser (model, OpenRouter relay, SDK, or stream transport).
• If Langfuse records a complete argument object/string but nanobot logs the truncated value, that strongly points to nanobot's stream assembly or parsing path.
• If Langfuse shows only XML-style text and no structured tool_calls, this is an unsupported upstream textual tool-call format.

Langfuse is not a byte-for-byte HTTP/SSE capture, so if it normalizes or omits the tool arguments, we would still need the raw OpenRouter response/stream.

Separately, the supplied logs do confirm a nanobot robustness issue: a malformed completion attempt leaves the sustained goal active, and the continuation policy amplifies it into repeated attempts. Even if the malformed call originates upstream, identical failing completion calls should be guarded by a regression test so they do not create a disruptive loop.

[maxmilian]

I traced the retry mechanism in the code — sharing what I found in case it helps scope the guard you mentioned.

On the tool call itself: agreed that the <function=complete_goal> XML form is unsupported, and separately complete_goal isn't a registered tool at all — the goal-completion tool is update_goal with action='complete' (nanobot/agent/tools/long_task.py, UpdateGoalTool.name == "update_goal"). So with xiaomi/mimo-v2.5 emitting complete_goal(...), the goal simply never gets marked complete, and it stays active.

Why it then churns (the part worth guarding): while the goal stays active, AgentRunner re-injects a sustained-goal continuation after each final response — _try_drain_injections(..., allow_goal_continue=True) at nanobot/agent/runner.py:580, which builds the continue message at runner.py:172-177. The asymmetry is here:

if injection_cycles < _MAX_INJECTION_CYCLES:      # real user injections are capped at 5
    injections = await self._drain_injections(spec)
    real_injection = bool(injections)
if not injections and allow_goal_continue and assistant_message is not None:
    ...
    injections = [self._build_goal_continue_message(spec)]   # goal-continue path
...
if real_injection:
    injection_cycles += 1                          # only real injections increment

The goal-continue injection takes the real_injection = False branch, so it never increments injection_cycles and is not bounded by _MAX_INJECTION_CYCLES (5) the way user injections are. Within a run it's still capped by max_iterations, and across runs the max-iteration path caps at _MAX_GOAL_CONTINUATION_ROUNDS = 12 (nanobot/session/turn_continuation.py) — so it's bounded, not literally infinite, but a model that keeps failing to emit a valid update_goal(action='complete') will burn the full iteration budget every run for up to 12 continuation rounds. From the user's side that's the "endless" churn.

Possible guard, matching your note: track consecutive goal-continue injections that produced no successful goal-state mutation (and/or no recognized tool call), and stop re-injecting after a small threshold — mirroring _MAX_INJECTION_CYCLES for the goal-continue path — surfacing a single message instead of silently re-prompting. That leaves the (correctly rejected) XML-parsing question untouched and only addresses the disruptive-repeat behavior.

Happy to put up a PR along those lines if the direction sounds right to you.