Summary

Fixes #11044 — outbound Telegram messages arrive out of order when multiple tool results fire concurrently.

Problem

Tool result callbacks in agent-runner-execution.ts are dispatched as fire-and-forget async tasks via pendingToolTasks. Each callback independently runs through typing signals and message delivery with no ordering guarantee. When multiple tool calls complete near-simultaneously, network latency jitter causes messages to arrive at the user in the wrong order.

Tool A completes → fires async send (slow network) ──────────────→ arrives 2nd
Tool B completes → fires async send (fast network) ───→ arrives 1st

This is consistently visible on Telegram and has been confirmed by multiple users.

Root Cause

The onToolResult handler creates independent promises added to a Set<Promise>:

const task = (async () => { /* send */ })();
params.pendingToolTasks.add(task);  // No ordering — runs concurrently

The set is only Promise.allSettled() after the run completes, by which point messages are already out of order.

Fix

Replace the fire-and-forget pattern with a serialized promise chain. Each tool result awaits completion of the previous one before starting its own typing signal and delivery:

let toolResultChain: Promise<void> = Promise.resolve();
return (payload: ReplyPayload) => {
  const task = (toolResultChain = toolResultChain.then(async () => {
    // normalize, signal typing, deliver — in order
  }))
    .catch(/* ... */)
    .finally(() => { params.pendingToolTasks.delete(task); });
  params.pendingToolTasks.add(task);
};

The IIFE creates the chain once per agent run. Each invocation appends to the chain, guaranteeing FIFO delivery. The existing pendingToolTasks tracking is preserved so the post-run drain (Promise.allSettled) still works correctly.

What this does NOT change

• Block reply delivery — already serialized via BlockReplyPipeline and sendChain
• Reply dispatcher — already serialized via its own sendChain (enqueue())
• Tool result content/filtering — normalizeStreamingText, heartbeat stripping, silent reply detection are all untouched
• Error handling — individual failures are still caught and logged without breaking the chain

Test

Added a test that fires two tool results concurrently where the first has higher simulated latency than the second. Verifies delivery order matches dispatch order (FIFO), not completion order.

25/25 tests passing

Greptile Summary

This PR introduces serialized tool result delivery to fix out-of-order message delivery on Telegram when multiple tool calls complete concurrently. The fix replaces fire-and-forget async task dispatching with a promise chain that ensures FIFO delivery order.

Key changes:

• Wraps onToolResult handler in an IIFE that creates a closure with a toolResultChain variable
• Each tool result callback appends to the chain via .then(), guaranteeing sequential execution
• Preserves existing pendingToolTasks tracking for post-run drain
• Adds test verifying delivery order matches dispatch order despite variable latency

Critical issue found:

• The .catch() error handler is applied AFTER the chain assignment, meaning toolResultChain contains an unhandled promise. If any tool result throws an error, subsequent tool results will chain onto a rejected promise and fail immediately, breaking the serialization guarantee. The .catch() must be moved inside the assignment parentheses to ensure the chain continues after errors (see inline comment).

Confidence Score: 2/5

• This PR is NOT safe to merge due to a critical error handling bug
• The implementation has the right idea (promise chain serialization) but contains a critical bug where errors break the chain. The .catch() handler is applied after the chain assignment, so toolResultChain stores an unhandled promise. When any tool result throws, subsequent results will chain onto a rejected promise and fail immediately instead of continuing. This defeats the serialization guarantee and could cause message loss or ordering issues in error scenarios.
• src/auto-reply/reply/agent-runner-execution.ts requires immediate attention to fix the error handling bug before merge

_{Last reviewed commit: ac53614}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}