Upstream issue draft — OpenClaw

Repo: https://github.com/openclaw/openclaw/issues/new Title: answerCallbackQuery timeout cluster on Telegram bots — late ACK because callback handler awaits model response

Summary

When a Telegram user presses an inline-keyboard button on a bot deployed via OpenClaw, the bot's callback handler invokes the model before sending answerCallbackQuery. On any model with mean latency > 15 s (every locally-served LLM in our deployment, and most reasoning-mode candidates), the ACK arrives late and Telegram rejects it with HTTP 400:

[telegram] answerCallbackQuery failed: ... (400: Bad Request: query is too old and response timeout expired or query ID is invalid)

Empirically observed on openclaw 2026.5.2 (8b2a6e5) running on macOS 25.4.0 / arm64 with qwen2.5:14b (mean 27.7 s) — 13 callback-query timeouts in a single 3.5-hour window on 2026-05-09 06:05–09:36 EDT, all on bot chat_id=8667951543.

The associated sendMessage call usually succeeds — so the user sees the bot reply, but the spinning "Loading…" indicator on the inline keyboard never resolves. UX glitch, not data loss.

Symptom

2026-05-09T06:05:12.418-04:00 [telegram] answerCallbackQuery failed: callback_query_id=...; chat=8667951543: 400 Bad Request: query is too old and response timeout expired or query ID is invalid
[bot] sendMessage chat_id=8667951543 length=487  ← model reply arrives ~22s after button press; succeeds

Root cause (analysis)

The callback dispatch flow in bot-Ce301bOE.js appears to be:

1. Telegram delivers callback_query to bot.
2. Bot invokes model with the query payload.
3. Bot waits for model's full response.
4. Bot calls answerCallbackQuery(text=<model_response_first_line>).
5. Bot calls sendMessage(text=<model_response_full>).

Step 4's text comes from the model, so it has to wait for step 3. Telegram's hard limit on callback_query ID validity is ~15 s; any model whose mean latency exceeds that window will routinely fail step 4.

Proposed fix

Standard Telegram bot pattern: ACK the callback BEFORE invoking the model.

// Pseudocode
async function handleCallbackQuery(query) {
  // 1. Acknowledge immediately, with empty text or a "Loading…" toast.
  await telegram.answerCallbackQuery(query.id, { text: "" });

  // 2. NOW invoke the model.
  const reply = await agent.process(query.data);

  // 3. Send reply via sendMessage (or editMessageText if the original message
  //    should be updated in place).
  await telegram.sendMessage(query.message.chat.id, reply);
}

This separates the callback ACK (which has a 15s deadline) from the model response (which can take as long as it needs).

Alternatives considered

• Set cache_time on answerCallbackQuery — limited; Telegram still enforces the ~15s validity on the original callback ID regardless of cache_time.
• Avoid callback-query interactions for high-latency replies — workaround, not fix; user-facing UX still requires inline keyboards for some flows.
• Switch to a faster model — independently desirable but does not solve the root issue (the 15s deadline is a hard Telegram limit, no local model reliably fits inside it).

Environment

• openclaw 2026.5.2 (8b2a6e5)
• macOS 25.4.0 (Darwin 25.4.0) / arm64 / Mac Mini M4 Pro
• Models tested: qwen2.5:14b (Q4_K_M, mean 27.7s); reproduced on every locally-served LLM ≥14B
• Telegram bot library: bundled (no override)

What I'd expect

answerCallbackQuery returns 200 OK consistently regardless of how long the model takes. The inline-keyboard "Loading…" indicator resolves within 1–2 seconds of the button press.

Workaround in place

None directly — the user sees the spinning indicator linger but the bot reply still arrives via sendMessage. Tracked locally as Operational #6 in docs/18-chatbot-improvement-plan.md.

Attachments / extra detail available on request

• Gateway log excerpts spanning the 13-error cluster on 2026-05-09 06:05–09:36 EDT
• Latency distribution across all 26 prompts × 3 trials × n=4 candidate models from ci/runs/agent-bench-2026-05-09-1333-phase5-q5-incumbent.md and siblings — confirms no locally-served LLM fits inside 15s consistently