openclaw - ✅(Solved) Fix [Bug]: payloads=0 incomplete-turn error in regular interactive chat sessions (not cron) — persists after #40868 closed [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71454Fetched 2026-04-26 05:12:35
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Participants
Timeline (top)
cross-referenced ×2closed ×1labeled ×1

After #40868 was closed, stopReason=stop payloads=0 still occurs in regular interactive chat sessions (not cron/isolated runs) on 2026.4.23. The agent completes successfully but the reply is never surfaced to the user, who sees "Agent couldn't generate a response" and must check backend logs to read the actual reply. Additionally, stopReason=toolUse payloads=0 also occurs mid-tool-execution.

Error Message

Gateway log shows: incomplete turn detected: stopReason=stop payloads=0 — surfacing error to user User sees error message. Actual reply is only visible in backend session logs. Occurs both on stopReason=stop and stopReason=toolUse. 2026-04-25T10:19:49+08:00 [agent/embedded] incomplete turn detected: runId=0a954dcc sessionId=cabed389 stopReason=stop payloads=0 — surfacing error to user 2026-04-25T10:40:13+08:00 [agent/embedded] incomplete turn detected: runId=a98382f4 sessionId=cabed389 stopReason=stop payloads=0 — surfacing error to user 2026-04-25T10:57:13+08:00 [agent/embedded] incomplete turn detected: runId=2c65bc9a sessionId=508202bd stopReason=stop payloads=0 — surfacing error to user 2026-04-25T11:35:07+08:00 [agent/embedded] incomplete turn detected: runId=b2c8b084 sessionId=508202bd stopReason=stop payloads=0 — surfacing error to user 2026-04-25T12:19:17+08:00 [agent/embedded] incomplete turn detected: runId=78547af0 sessionId=508202bd stopReason=toolUse payloads=0 — surfacing error to user 5 occurrences in ~2 hours during regular interactive chat. Note the last entry shows stopReason=toolUse — the incomplete-turn error also triggers mid-tool-execution, not only on clean stop turns.

Root Cause

After #40868 was closed, stopReason=stop payloads=0 still occurs in regular interactive chat sessions (not cron/isolated runs) on 2026.4.23. The agent completes successfully but the reply is never surfaced to the user, who sees "Agent couldn't generate a response" and must check backend logs to read the actual reply. Additionally, stopReason=toolUse payloads=0 also occurs mid-tool-execution.

Fix Action

Fixed

PR fix notes

PR #71467: fix(agent): recover blank streamed replies from final answer

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

If this PR fixes a plugin beta-release blocker, title it fix(<plugin-id>): beta blocker - <summary> and link the matching Beta blocker: <plugin-name> - <summary> issue labeled beta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.

  • Problem: interactive chat runs can finish with stopReason=stop but payloads=0 when the streamed assistant text array contains only whitespace, causing the gateway to surface the generic incomplete-turn error instead of the final answer.
  • Why it matters: users see “Agent couldn't generate a response” even though the agent completed and persisted a usable final answer.
  • What changed: payload construction now ignores whitespace-only streamed assistant texts before deciding whether fallback to the final assistant message is needed.
  • What did NOT change (scope boundary): incomplete-turn retry/liveness behavior, tool-use handling, and provider-specific model behavior are unchanged.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #71454
  • Related #40868
  • This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause: buildEmbeddedRunPayloads treated assistantTexts.length > 0 as proof that a streamed user-visible reply existed, even when every streamed entry was blank/whitespace.
  • Missing detection / guardrail: there was coverage for completely missing streamed text falling back to final-answer content, but not for whitespace-only streamed text.
  • Contributing context (if known): phased final-answer extraction already had the correct final reply, but the blank streamed array blocked fallback.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/agents/pi-embedded-runner/run/payloads.test.ts
  • Scenario the test should lock in: whitespace-only streamed assistant text falls back to the persisted final-answer assistant content.
  • Why this is the smallest reliable guardrail: the bug is isolated to payload assembly fallback selection.
  • Existing test that already covers this (if any): existing fallback test covered absent streamed text, but not whitespace-only entries.
  • If no new test is added, why not: N/A — new regression test added.

User-visible / Behavior Changes

Interactive chat replies that previously produced the generic incomplete-turn error can now deliver the final assistant answer when it is present in the stored assistant message.

Diagram (if applicable)

Before:
[assistantTexts: ["   "]] -> [fallback skipped] -> [payloads=0] -> [generic incomplete-turn error]

After:
[assistantTexts: ["   "]] -> [blank text ignored] -> [final_answer fallback] -> [reply delivered]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • OS: macOS / Darwin 25.5.0
  • Runtime/container: Node.js 25.9.0, pnpm 10.33.0
  • Model/provider: N/A
  • Integration/channel (if any): Telegram-style interactive chat symptom from issue report
  • Relevant config (redacted): default payload assembly path

Steps

  1. Build embedded run payloads with assistantTexts: [" "].
  2. Provide a lastAssistant with phased final_answer text.
  3. Inspect generated outbound payloads.

Expected

  • The final-answer text is emitted as the outbound payload.

Actual

  • Before this change, no payload was emitted because the blank streamed text array blocked fallback.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

pnpm test -- --run src/agents/pi-embedded-runner/run/payloads.test.ts

✓ unit-fast src/agents/pi-embedded-runner/run/payloads.test.ts (18 tests)
Test Files  1 passed (1)
Tests       18 passed (18)

Typecheck note:

NODE_OPTIONS=--max-old-space-size=8192 pnpm exec tsc --noEmit --pretty false
src/agents/pi-embedded-runner.sanitize-session-history.test.ts(985,13): error TS2352: Conversion of type 'AgentMessage' to type 'Record<string, unknown>' may be a mistake...

This appears unrelated to this PR; this change only touches run/payloads.ts and its payload unit test.

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: regression unit test passes; existing payload tests still pass.
  • Edge cases checked: media-directive fallback behavior still uses non-empty assistant text normalization for comparison; whitespace-only streamed text no longer suppresses final-answer fallback.
  • What you did not verify: full repository typecheck due to unrelated existing TS2352 error noted above; live Telegram reproduction.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: Filtering blank streamed entries could alter behavior if whitespace-only assistant replies were intentionally user-facing.
    • Mitigation: whitespace-only payloads are not deliverable user-visible content; silent replies are handled separately by existing NO_REPLY logic.

Changed files

  • CHANGELOG.md (modified, +1/-1)
  • src/agents/pi-embedded-runner/run/payloads.test.ts (modified, +23/-0)
  • src/agents/pi-embedded-runner/run/payloads.ts (modified, +6/-4)

Code Example

2026-04-25T10:19:49+08:00 [agent/embedded] incomplete turn detected: runId=0a954dcc sessionId=cabed389 stopReason=stop payloads=0 — surfacing error to user
2026-04-25T10:40:13+08:00 [agent/embedded] incomplete turn detected: runId=a98382f4 sessionId=cabed389 stopReason=stop payloads=0 — surfacing error to user
2026-04-25T10:57:13+08:00 [agent/embedded] incomplete turn detected: runId=2c65bc9a sessionId=508202bd stopReason=stop payloads=0 — surfacing error to user
2026-04-25T11:35:07+08:00 [agent/embedded] incomplete turn detected: runId=b2c8b084 sessionId=508202bd stopReason=stop payloads=0 — surfacing error to user
2026-04-25T12:19:17+08:00 [agent/embedded] incomplete turn detected: runId=78547af0 sessionId=508202bd stopReason=toolUse payloads=0 — surfacing error to user
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

After #40868 was closed, stopReason=stop payloads=0 still occurs in regular interactive chat sessions (not cron/isolated runs) on 2026.4.23. The agent completes successfully but the reply is never surfaced to the user, who sees "Agent couldn't generate a response" and must check backend logs to read the actual reply. Additionally, stopReason=toolUse payloads=0 also occurs mid-tool-execution.

Steps to reproduce

Start a regular interactive chat session via Telegram Send a message to the agent Agent processes and completes the turn (stopReason=stop) User receives "Agent couldn't generate a response. Please try again." instead of the reply Gateway log shows: incomplete turn detected: stopReason=stop payloads=0 — surfacing error to user

Expected behavior

Agent reply should be delivered to the user normally.

Actual behavior

User sees error message. Actual reply is only visible in backend session logs. Occurs both on stopReason=stop and stopReason=toolUse.

OpenClaw version

2026.4.23

Operating system

Rocky Linux

Install method

No response

Model

google/gemini-3-flash-preview

Provider / routing chain

Local OpenClaw gateway → google provider → gemini-3-flash-preview

Additional provider/model setup details

No response

Logs, screenshots, and evidence

2026-04-25T10:19:49+08:00 [agent/embedded] incomplete turn detected: runId=0a954dcc sessionId=cabed389 stopReason=stop payloads=0 — surfacing error to user
2026-04-25T10:40:13+08:00 [agent/embedded] incomplete turn detected: runId=a98382f4 sessionId=cabed389 stopReason=stop payloads=0 — surfacing error to user
2026-04-25T10:57:13+08:00 [agent/embedded] incomplete turn detected: runId=2c65bc9a sessionId=508202bd stopReason=stop payloads=0 — surfacing error to user
2026-04-25T11:35:07+08:00 [agent/embedded] incomplete turn detected: runId=b2c8b084 sessionId=508202bd stopReason=stop payloads=0 — surfacing error to user
2026-04-25T12:19:17+08:00 [agent/embedded] incomplete turn detected: runId=78547af0 sessionId=508202bd stopReason=toolUse payloads=0 — surfacing error to user

Impact and severity

No response

Additional information

5 occurrences in ~2 hours during regular interactive chat. Note the last entry shows stopReason=toolUse — the incomplete-turn error also triggers mid-tool-execution, not only on clean stop turns.

extent analysis

TL;DR

Investigate and potentially adjust the payload handling for stopReason=stop and stopReason=toolUse in the OpenClaw gateway to ensure replies are surfaced correctly to users.

Guidance

  • Review the OpenClaw gateway logs for patterns or commonalities among the occurrences of "incomplete turn detected" errors, focusing on stopReason=stop and stopReason=toolUse.
  • Verify the payload content for these errors to understand why payloads=0 is being reported, which might indicate an issue with payload construction or handling.
  • Check the integration with the google/gemini-3-flash-preview model to ensure that the response formatting and payload structure match the expectations of the OpenClaw gateway.
  • Consider adding logging or debugging statements to track the flow of responses from the model through the gateway to identify where the reply is being lost or misinterpreted.

Example

No specific code example can be provided without more details on the OpenClaw gateway's internal workings or the exact nature of the payload issue. However, ensuring that the response from the model is correctly formatted and that the gateway is configured to handle such responses is crucial.

Notes

The issue seems to be related to how the OpenClaw gateway handles certain types of responses or errors from the model, particularly those with stopReason=stop or stopReason=toolUse. The fact that the actual reply is visible in the backend logs but not surfaced to the user suggests a problem in the response handling or routing logic.

Recommendation

Apply a workaround by closely examining and potentially modifying the payload handling logic in the OpenClaw gateway to correctly surface replies to users, especially for stopReason=stop and stopReason=toolUse cases, as this seems to be where the issue lies.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Agent reply should be delivered to the user normally.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: payloads=0 incomplete-turn error in regular interactive chat sessions (not cron) — persists after #40868 closed [1 pull requests, 1 participants]