Defense-in-depth safety net for #81628: even with the cron-tool fix in
place, any other code path that ever produces a 33-char LINE-shaped
recipient missing its leading capital (C/U/R) would otherwise hit the
LINE API and return HTTP 400 with no permanent-error signal, causing
delivery-recovery to retry five times before moving the entry to
failed/.
normalizeTarget now throws "Recipient is not a valid LINE id ..." when
the post-strip value looks like a LINE id but the case was lost. The
message matches the existing /recipient is not a valid/i pattern in
delivery-queue-recovery's PERMANENT_ERROR_PATTERNS, so recovery moves
the entry to failed/ on the first attempt instead of silently retrying.
Short fixtures (length < 33) are left alone so existing tests using
"U123", "line:user:1", etc. keep working.
LINE chat ids are case-sensitive (push requires capital C/U/R) but the
session key holds the peer id lowercased for canonical routing. When
cron-tool runs without currentDeliveryContext (delivery-recovery, queue
replay after reply-token expiry), inferDeliveryFromSessionKey was
lifting the lowercased fragment straight into delivery.to, producing a
value LINE rejects with HTTP 400 — the job retried five times silently
and the dashboard reported "delivered" while the LINE group received
nothing.
Refuse the session-key fallback for channel === "line" so the missing
target surfaces explicitly instead of scheduling an undeliverable job.
Fix Gemini/Gemma attributed and self-closing <final> tag leaks across sanitizer, reasoning cleanup, and embedded Pi streaming enforcement.\n\nProof posted in PR body: focused Vitest, formatting, diff check, real Google Gemini/OpenRouter/local Gemma live output.
DeepSeek V4 via OpenRouter injects reasoning_content: "" on assistant
messages that contain tool_calls. The sanitizer only deleted the field
when it was not a string, so empty strings slipped through and were
replayed on follow-up turns. OpenRouter rejects the field with an
HTTP 500 Internal Server Error instead of a descriptive 4xx, breaking
every subsequent tool-call turn for the session.
Also strip empty-string reasoning for the same reason.
Closes#82150
Fix Codex app-server turns that go quiet after the last non-assistant current-turn item completes without turn/completed.\n\nMaintainer proof: focused watchdog regression passed on rebased head, diff whitespace check passed, and local OpenClaw CLI + WebSocket app-server transport proof observed turn/interrupt after the short idle watchdog.\n\nCo-authored-by: funmerlin <funmerlin@users.noreply.github.com>
Route Discord and Slack prepared message turns through the core prepared-turn runner directly.
Local proof before landing:
- node scripts/run-vitest.mjs src/channels/turn/kernel.test.ts extensions/discord/src/monitor/message-handler.process.test.ts extensions/slack/src/monitor/message-handler/prepare.test.ts extensions/slack/src/monitor/message-handler/dispatch.preview-fallback.test.ts
- node scripts/run-tsgo.mjs -p tsconfig.core.json --incremental false
- node scripts/run-tsgo.mjs -p tsconfig.extensions.json --incremental false
- OPENCLAW_TESTBOX_REMOTE_RUN=1 OPENCLAW_VITEST_MAX_WORKERS=1 pnpm check:changed
- codex-review clean after accepted Slack bot-loop history cleanup finding was fixed in core
GitHub checks had no failures; Blacksmith/GitHub runner jobs were still queued when maintainer approved landing based on local proof.
canBridgeNoDeviceChatApprovalFromBackend used matchesRequiredString for
turnSourceTo, which returns false when expected is null. Channels without
a recipient concept (webchat, control-ui) leave turnSourceTo null on both
the approval snapshot and the replay params, so every backend
gateway-client replay was rejected with APPROVAL_CLIENT_MISMATCH after
the approval prompt was answered. turnSourceAccountId and turnSourceThreadId
in the same function already use matchesOptionalString for the same reason;
turnSourceTo was missed when PR #78728 added the helper.
Switch to matchesOptionalString so null-on-both-sides matches. Cross-channel
replay protection is preserved by the existing required turnSourceChannel
and sessionKey checks. Added a regression test asserting webchat replay
with null turnSourceTo is accepted.
