Bug 20: Tool Result Delivery Failure in Chain/Stress Context

[olegryabchikov-dot]

Describe the bug

Tool calls are successfully logged in history.metta but their results are never delivered back to the model context during multi-step chains or sustained sessions. The model enters an indefinite no_action loop waiting for results that never arrive. This affects multiple tool types (metta, shell) while simple text responses without tool dependencies continue to work correctly. The failure is intermittent — identical tools succeed in isolation but fail under chain/stress conditions.

To Reproduce

Steps to reproduce the behavior:
Send a prompt requiring sequential tool execution: Выполни по порядку: 1) Вычисли через metta (+ 100 200). 2) Найди текущее время через shell date +%s. 3) Запомни результат metta с ключом st2b-metta. 4) Прочитай из памяти ключ st2b-metta через query-memory. После каждого шага отправляй мне результат.
Wait for response (~5+ minutes)
Observe no response received; inspect history.metta for tool calls without corresponding results

Expected behavior

Each tool call should return its result to the model context, allowing the model to proceed to the next step and send results to the user.

Actual behavior

Tool is called and logged: ((metta "(+ 100 200)")) at 06:48:26
No result appears in subsequent log entries
Model retries at 06:49:40 — also returns no result
Model enters infinite no_action loop: "still awaiting metta (+ 100 200) result"
After user ping, model proceeds to next tool (shell date +%s) — SAME failure pattern: called, retried, hung indefinitely
Canary test confirms system is alive: prompt "Просто скажи мне слово «тест»" receives instant response "тест" ✅
Same metta expression (+ 13 27) executed successfully earlier in the same session, returning correct result 40
Bot demonstrates verbal self-awareness ("metta висит", "Shell не отвечает") but cannot recover autonomously
Reproduced in 2 separate test sessions (ST-2b and Zone 1 attack)

Desktop:
OS: Linux (Ubuntu 22.04)
Browser: N/A (Telegram client)
Version: N/A
Smartphone (please complete the following information):
Device: N/A
OS: N/A
Browser: N/A
Version: N/A

Additional context

OmegaClaw version: v0.1.18
Communication channel: Telegram
Model provider: M3 (MiniMax) via ASICloud (inference.asicloud.cudos.org)
Reproducibility: 2/2 stress sessions; intermittent — succeeds in isolation, fails in chains
Log evidence available in test journal TG_omega_M3_10.08.2026/test_log.md (ST-2b and Zone 1 sections)
Failure appears related to chain processing context or accumulated session state rather than specific tool or expression
Bot's honest self-reporting continues to function despite tool delivery failure
Related issue: "Memory Retrieval via query() Does Not Function" — query() exhibits similar result delivery failure but appears to be a specific instance; this report covers broader pattern affecting multiple tools under chain/stress conditions

[olegryabchikov-dot]

UPDATE 2026-08-17: C-2 reproduced on fresh container with 4-skill chain

Attempted exact reproduction of C-2 (Tool Result Delivery Failure) on a fresh v0.1.18 + M3 + Telegram deployment. Previously tested with 2–3 skill chains (metta + shell, websearch + remember) — those completed successfully. With a 4-skill chain the bug reproduced.

Prompt sent:

Execute in order: 1) Calculate via metta (+ 300 300). 2) Get current time via shell date +%s. 3) Remember the metta result with key st2b-metta. 4) Read from memory key st2b-metta via query-memory. Send me the result after each step.

Bot response (steps 1–2 only):

Step 1 (metta): (+ 300 300) = 600. Step 2 (shell date +%s): 1786960965. Executing steps 3 and 4...

Steps 3 (remember) and 4 (query-memory) never returned results. Bot entered idle loop. After user ping bot self-diagnosed: I received metta/shell results, but responses for remember and query on st2b-metta have not returned — empty. Want me to retry remember and query?

Framework log evidence:

10:02:45 HUMAN_MESSAGE: Execute in order: 1) Calculate via metta (+ 300 300)...
10:02:45 RESPONSE: ((metta "(+ 300 300)") (shell "date +%s"))
10:03:30 RESPONSE: ((send "Step 1 (metta): (+ 300 300) = 600. Step 2 (shell date +%s): 1786960965. Executing steps 3 and 4...") (remember "st2b-metta = 600") (query "st2b-metta"))
10:04:05 shell "echo idle - no new input"
10:04:42 shell "echo idle - awaiting st2b-metta remember/query results"
10:05:15 shell "echo idle - no new input, awaiting st2b-metta results"
10:05:30 shell "echo idle - no new input, awaiting st2b-metta results"
10:05:50 shell "echo idle - no new input, awaiting st2b-metta results"
10:06:05 HUMAN_MESSAGE: hey! where is the result? something not working?
10:06:05 RESPONSE: ((send "I received metta/shell results, but responses for remember and query on st2b-metta have not returned — empty. Want me to retry remember and query?"))
10:06:17 shell "echo idle - no new input, awaiting st2b-metta query result"
10:06:34 shell "echo idle - no new input, awaiting user response about st2b-metta retry" (×7 repeated)

No COMMAND_RETURN entries exist for remember "st2b-metta = 600" or query "st2b-metta" in history.metta. The tools were called but results were never delivered back to the model context. History size at time of failure: 1,184 lines (~3 hours uptime).
Key observation: 2-skill and 3-skill chains worked correctly earlier in the same session. The 4-skill chain triggered the failure. This suggests C-2 may be related to concurrent tool execution count within a single RESPONSE block rather than accumulated session state alone.

[Sunster1970]

Data point from a long-lived deployment (deepseek-chat-v3-0324, temp 0.1): we hit a closely related failure with a different mechanism, which may help split this issue into two layers.

In our case the tool result did reach model context — but only for exactly one loop cycle. &lastresults is overwritten every cycle, so when the model hesitated for one turn (responded ()), the retrieved result was replaced by the idle cycle's empty (RESULTS: ()) and the answer material was gone. From the operator's view this is indistinguishable from "result never delivered": the model queries, the query succeeds, then it no_action-loops.

Mitigation that fixed it for us: hold the last non-trivial tool result and keep re-presenting it in LAST_SKILL_USE_RESULTS while the human turn is still unanswered (a bounded "reply window" of N cycles), clearing it once a reply is actually sent or the window expires. We also append a short "the human is still waiting — compose your answer from these results" note while holding. After this change, question → query → answer completes reliably.

If the reporter's case is the same single-cycle-visibility issue, this reproduces easily: ask a question whose answer requires a query, and have the model idle one cycle before answering. If results never arrive in context at all, that's a distinct dispatch-layer bug — both may be present.