PR #70425: fix(pi-embedded-runner): suppress incomplete-turn warning after clean messaging-tool delivery

• Repository: openclaw/openclaw
• Author: neeravmakwana
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/70425

Description (problem / solution / changelog)

Fixes #70396.

Summary

When the Pi embedded agent runner finishes a turn with payloads=0 but the assistant has already delivered user-visible content through a messaging tool (didSendViaMessagingTool=true) and the model reports a clean terminal state (stopReason=stop), the runner was still surfacing a user-facing error:

⚠️ Agent couldn't generate a response. Note: some tool actions may have already been executed — please verify before retrying.

That warning was a false positive — the user had already received the reply via the messaging tool. It was especially confusing on channels like Telegram where users also saw the bubble in their chat alongside the actual assistant message, implying something had failed.

This change adds a narrow early return in resolveIncompleteTurnPayloadText for exactly that "clean + already delivered" case. Every other incomplete-turn path is unchanged.

Root cause

resolveIncompleteTurnPayloadText deliberately does not treat messaging-tool sends as user-visible payloads (payloadCount is derived from direct assistant payloads only, not from messaging tool output). That is correct — those payloads are delivered out-of-band by the channel. But when the flag didSendViaMessagingTool=true is combined with a clean stopReason=stop and no lastToolError, the function still fell through into the reasoning-only / empty-terminal warning branches, producing the false-positive warning. The scenario was also locked in by run.incomplete-turn.test.ts asserting that the warning fires.

Fix

In src/agents/pi-embedded-runner/run/incomplete-turn.ts, after the early exits for abort, timeout, compaction-timeout, prompt errors, payload count, deterministic approval prompts, yields, client tool calls, and silent replies, add one more:

if (
  params.attempt.didSendViaMessagingTool &&
  !params.attempt.lastToolError &&
  stopReason === "stop"
) {
  return null;
}

All three conditions together are required:

• didSendViaMessagingTool: the messaging tool executed and reported a successful send during this turn.
• !lastToolError: no tool error was recorded; a tool error still routes to the existing "verify before retrying" warning.
• stopReason === "stop": the upstream provider ended the turn cleanly. StopReason from @mariozechner/pi-ai does not include end_turn; toolUse/length/error/aborted all continue to hit their existing branches.

Why the fix is safe

• The suppression is scoped to a narrow, positively-evidenced "delivery succeeded" state. It does not silence any real error path:
  • stopReason=error → unchanged, still shows "verify before retrying".
  • stopReason=toolUse with tool-use interrupted → unchanged, still shows the warning.
  • Aborted / timed-out / prompt error → unchanged (earlier guards already return).
  • Reasoning-only or empty-response turns without didSendViaMessagingTool → unchanged.
• replayMetadata.replaySafe already reflects hadPotentialSideEffects, so abandoned-run / replay-invalid tracking (resolveReplayInvalidFlag, resolveRunLivenessState) still treat this attempt as having had side effects. Future retries continue to be gated correctly.
• The existing test in run.incomplete-turn.test.ts that previously asserted the warning when a messaging tool had already delivered and the turn ended cleanly was encoding the buggy behavior; it is updated to assert the corrected behavior. Other regression tests covering tool errors, interrupted tool use, reasoning-only retries, and silent replies all continue to pass unmodified.

Security / runtime controls unchanged

• No change to tool approval, policy gating, sandbox, or runtime-enforced permissions. Messaging-tool sends still go through the normal tool pipeline before didSendViaMessagingTool is ever set.
• No change to system prompts, instructions, or any behavior that depends on prompt text — the gate is on runtime state (didSendViaMessagingTool, lastToolError, stopReason), not on prompt content.
• No new exports, no new configuration keys, no doc/help/generated-artifact drift.
• No change to lazy/module boundaries; no pnpm build surface affected.
• Bundled-plugin and channel boundaries unaffected; change is confined to src/agents/pi-embedded-runner/run/** core runner logic.

Tests run

• pnpm test src/agents/pi-embedded-runner/run.incomplete-turn.test.ts — 51 passed (49 existing + 2 new targeted cases for the new gate).
• pnpm test src/agents/pi-embedded-runner/run.empty-error-retry.test.ts src/agents/pi-embedded-runner/run.overflow-compaction.test.ts — 19 passed.
• pnpm test src/agents/pi-embedded-runner/ — 645 passed across 54 test files.
• pnpm check:changed --staged (core prod typecheck + core lint + import-cycle / webhook / pairing guards + changed-scope tests) — 287 tests passed across 17 files, all guards green.

Behavior

• Before: Telegram/Discord users saw a spurious "⚠️ Agent couldn't generate a response" bubble after the agent had already replied via the messaging tool.
• After: the assistant reply stands alone; no extra warning when the turn ended cleanly.

Made with Cursor

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/agents/pi-embedded-runner/run.incomplete-turn.test.ts (modified, +46/-4)
• src/agents/pi-embedded-runner/run/incomplete-turn.ts (modified, +11/-0)