#116512·openclaw

[Bug]: Telegram progress duplicates first commentary when snapshot IDs change

Author: CuttingwaterCreated Jul 30, 2026Updated Oct 2, 2026
LabelsP2clawsweeper:needs-live-reproimpact:message-lossissue-rating: 🐚 platinum hermit

Bug type

Behavior bug

Is this a beta blocker?

No

Summary

In Telegram streaming.mode: "progress" with commentary enabled, the first user-visible commentary/preamble can appear twice in the same progress bubble even though the model emitted the commentary only once.

The duplicate occurs when a provider bridge forwards the same normalized commentary as a streaming snapshot and then as a completed snapshot with different itemId values. pushCommentaryProgress() currently deduplicates by line ID, so both snapshots are appended.

Reproduction steps

  1. Configure Telegram progress commentary:
json
{
  "streaming": {
    "mode": "progress",
    "progress": {
      "commentary": true,
      "label": false,
      "toolProgress": false
    }
  }
}
  1. At the progress compositor boundary, send two adjacent preamble events containing the same normalized text but different item IDs:
typescript
await progress.pushCommentaryProgress("Checking the workspace", {
  itemId: "streaming-preamble",
});
await progress.pushCommentaryProgress("Checking   the workspace", {
  itemId: "completed-preamble",
});
  1. Inspect the Telegram progress preview.

A provider-level instance presents the same shape: a streaming preamble snapshot followed by its completed snapshot under a different ID.

Expected behavior

The adjacent snapshots represent one logical commentary message, so the progress bubble should contain:

Checking the workspace

once.

Actual behavior

The progress bubble contains the same first commentary twice. Later commentary messages are not duplicated unless they arrive in the same two-snapshot shape.

Root cause

pushCommentaryProgress() creates a compositor line keyed by itemId. Existing seenLineIds and merge behavior correctly handle repeated updates under the same ID, but cannot recognize equivalent adjacent commentary when the provider changes IDs between streaming and completion snapshots.

The text has already been normalized, so the compositor sees equal line.text values but distinct line.id values and appends both.

Proposed fix

Coalesce only an immediately adjacent Commentary line whose normalized text is identical. Replace the previous line with the newest line object so a later retraction using the completed item ID still works:

typescript
const previousLine = lines.at(-1);
if (
  typeof previousLine === "object" &&
  previousLine.label === "Commentary" &&
  previousLine.text === line.text
) {
  lines = [...lines.slice(0, -1), line];
  return false;
}

This is deliberately narrower than global text deduplication. Repeating the same commentary after an intervening tool or progress event remains valid and visible.

Regression tests

A local source patch at ee929dbb857c717a60f3b2b502db5a6dd31b5c11 adds:

  • a core compositor test with identical normalized commentary and different IDs;
  • a Telegram dispatch integration test using streaming-preamble and completed-preamble IDs.

Before the fix:

pnpm exec vitest run src/channels/progress-draft-compositor.test.ts --config vitest.config.ts --pool forks --testTimeout 10000

FAIL 1 / 36: expected one occurrence, received two

After the fix:

PASS src/channels/progress-draft-compositor.test.ts: 36 / 36
PASS extensions/telegram/src/bot-message-dispatch.progress-updates.test.ts: 25 / 25

A direct smoke against the generated runtime bundle produced occurrences: 1 after the patch.

OpenClaw version

2026.7.2-beta.5 (ee929db)

Operating system

macOS 26.5.2 arm64, Node.js 26.0.0

Installation method

Global npm installation under Homebrew Node

Additional evidence

For the observed production occurrence:

  • the native model transcript contained exactly one commentary item with the duplicated text;
  • the channel ingress log contained one inbound Telegram update;
  • the duplication was therefore introduced during progress rendering rather than by the model or duplicate inbound delivery.

Related but not duplicate: #111944 concerns commentary not being delivered at all. This report concerns delivered commentary being rendered twice when snapshot IDs change.