Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

LINE delivery-recovery and post-reply-token push paths emit recipient IDs that LINE rejects (lowercased first character or full session-key prefix kept as to), causing silent push failures while the dashboard reports the message as delivered.

Steps to reproduce

1. Bind a LINE account to an agent in openclaw.json and add the bot to a LINE group.
2. From the group, send the agent a request that takes longer than the LINE reply-token TTL (~60 seconds), e.g. a query that runs a DB lookup and emails the result.
3. The agent run completes and the messaging tool returns "sent"; the dashboard shows the assistant message as delivered.
4. The LINE group receives nothing.
5. Inspect ~/.openclaw/delivery-queue/failed/*.json — the to field is either lowercased (e.g. "cxxx..." instead of "Cxxx...") or contains the full session-key prefix (e.g. "line:group:Cxxx...").
6. Reproduce against the LINE API directly: pushing with a lowercase first character returns HTTP 400 "The property, 'to', in the request body is invalid"; the same call with capital Cxxx... returns HTTP 200.

Expected behavior

The agent's reply should reach the LINE group. The recipient ID passed to the LINE Messaging API should preserve the original casing returned by the inbound webhook (LINE chat IDs are case-sensitive and must start with capital C/U/R), and any session-key prefix such as line:group: should be stripped before being used as to. The inbound webhook → reply path within the reply-token TTL already behaves correctly — trajectory traces show to: "Cxxx..." with capital C — confirming the bug is specific to delivery-recovery and the post-token-expiry push path.

Actual behavior

The reply never arrives in the LINE group. ~/.openclaw/delivery-queue/failed/*.json shows queued payloads with to either lowercased (e.g. "uxxx..." with lowercase u) or set to the raw session-key string (e.g. "line:group:Cxxx..."). Gateway logs show [delivery-recovery] Retry failed for delivery <uuid>: 400 - Bad Request repeated 5 times per payload before they are moved to failed/. Direct curl reproduction confirms LINE returns HTTP 400 for the lowercased recipient and HTTP 200 for the same id with capital C.

OpenClaw version

2026.5.7 (eeef486)

Operating system

Ubuntu (Linux 6.17.0-23-generic, x64)

Install method

npm global

Model

anthropic-vertex/claude-opus-4-7

Provider / routing chain

openclaw -> @openclaw/line plugin (2026.5.7) -> LINE Messaging API

Additional provider/model setup details

Bug is on the channel delivery path, not the model provider path. The LINE plugin (@openclaw/line 2026.5.7) is bundled and configured in openclaw.json under channels.line. Multiple LINE accounts (sub-accounts under the same agent) are configured; the bug reproduces on every account.

Logs, screenshots, and evidence

Sanitized failed delivery payload from ~/.openclaw/delivery-queue/failed/:


{
  "channel": "line",
  "to": "uxxx...",                  // <-- lowercased; LINE expects "U..."
  "accountId": "<account-id>",
  "payloads": [{ "text": "..." }],
  "lastError": "400 - Bad Request"
}


Gateway log excerpt:


[delivery-recovery] Retry failed for delivery <uuid>: 400 - Bad Request
[delivery-recovery] Delivery <uuid> exceeded max retries (5/5) — moving to failed/


Direct LINE API verification (only the case of the first character differs):


# Lowercase first char (what core enqueues) → HTTP 400
curl -X POST https://api.line.me/v2/bot/message/push \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"to":"cxxx...","messages":[{"type":"text","text":"x"}]}'
# {"message":"The property, 'to', in the request body is invalid (line: -, column: -)"}

# Uppercase first char (the actual LINE id) → HTTP 200
curl -X POST https://api.line.me/v2/bot/message/push \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"to":"Cxxx...","messages":[{"type":"text","text":"x"}]}'
# {"sentMessages":[{"id":"...","quoteToken":"..."}]}


The `@openclaw/line` plugin's `normalizeTarget()` (in `markdown-to-line-CCWK6PJh.js`) correctly strips `line:(group|room|user):` prefixes and never mutates case. If every push went through it, neither failure mode would happen — the bug is on the core side, in `delivery-recovery` retries and in session-key → recipient resolution.

Impact and severity

Affected: every LINE account / agent that handles long-running tasks in groups (i.e. anything taking longer than the reply-token TTL of ~60s).
Severity: High — the agent's final reply is silently dropped while the dashboard shows it as delivered, so operators do not realize there is a problem until end users complain.
Frequency: Reproducible on every long-task push observed; we accumulated dozens of failed deliveries over a few weeks across multiple LINE accounts before noticing the pattern.
Consequence: End users in LINE groups never see long-task results (reports, query answers, status updates). Cron failure alerts also vanish, so cron job failures go unnoticed.

Additional information

Not a regression as far as we can tell — observed on 2026.5.7, no known earlier good version since this deployment was set up on 2026.5.x. Workaround in place: an out-of-band script that calls the LINE push API directly with normalized casing, used by agents instead of the built-in messaging tool when the reply token has expired.