# OpenClaw Telegram Delivery Review

## Context

Pipo (the OpenClaw agent) receives messages from Ignacio on Telegram, processes them (visible on the dashboard at `https://miopenclaw-vnic.tail9799d2.ts.net/`), but responses frequently fail to reach Telegram. This forces Ignacio to follow up again, wasting tokens and time.

## Findings

### Issue 1: Telegram Polling Stalls (PRIMARY)

The Telegram long-polling connection periodically stalls (~90-120s without a `getUpdates` response), causing a cascade:
1. Polling stall detected -> forces restart
2. During restart window, all outbound `sendMessage` calls fail with `Network request for 'sendMessage' failed!`
3. The `final reply failed` error means the AI's response is **lost** — never delivered to Telegram

**Stats from logs (Mar 16-18):**
- 177 successful vs 107 failed sendMessage calls (**37% failure rate**)
- 17 polling stalls detected across 3 days
- Worst hours: Mar 16 17:00-18:00 UTC — 76 failures vs 49 successes
- Mar 17 23:00 UTC — 11 failures vs 2 successes (almost total failure)

### Issue 2: Network Config Forcing IPv4-Only

In `~/.openclaw/openclaw.json` (line 2002-2005):
```json
"network": {
  "autoSelectFamily": false,
  "dnsResultOrder": "ipv4first"
}
```

- `autoSelectFamily: false` disables Node.js's automatic IPv4/IPv6 dual-stack failover
- On Oracle Cloud (which has dual-stack), this creates a single point of failure
- When IPv4 connections to `api.telegram.org` stall (Oracle Cloud networking quirks), there's no IPv6 fallback
- The `telegram.http` diagnostic flag is already enabled, confirming this was previously investigated but not resolved

### Issue 3: GPT-5.4 Backend Errors (Separate)

Today's logs also show repeated `server_error` from the OpenAI Codex backend (model `gpt-5.4`). This is an upstream OpenAI issue, not OpenClaw's fault, but it means some AI responses aren't generated at all.

### Non-Issues

- **Bot token**: Valid and working (messages do succeed ~63% of the time)
- **OpenClaw version**: 2026.3.13 (latest available)
- **Security config**: Correct — allowlist with chat ID 842987156
- **Retry config**: Already set to 6 attempts with 1.5s-90s backoff — the problem is the retries also fail because the whole network stack is stalled

## Plan

### Step 1: Fix Network Configuration

Edit `~/.openclaw/openclaw.json`, change the `channels.telegram.network` section:

```json
"network": {
  "autoSelectFamily": true,
  "dnsResultOrder": "ipv4first"
}
```

This enables Node.js's built-in dual-stack failover while still preferring IPv4. If IPv4 stalls, it will automatically try IPv6.

### Step 2: Increase Timeout

Change `timeoutSeconds` from 60 to 90 to give more headroom for slow responses (especially with reasoning models).

### Step 3: Verify and Monitor

After the config change, the gateway needs to pick up the new config. Since we **cannot restart the gateway** (per CLAUDE.md constraints — it's managed by Gemini CLI), we need to check if OpenClaw hot-reloads config changes. If not, we'll note this for the next natural restart.

Then monitor `/tmp/openclaw/openclaw-2026-03-16.log` for:
- Absence of "Polling stall detected" errors
- `autoSelectFamily=true` in the config log lines
- Consistent "sendMessage ok" without failures

### Files to Modify

- `~/.openclaw/openclaw.json` — lines 2002-2005 (network config), line 1995 (timeout)

### Verification

1. After config change: `grep "autoSelectFamily" /tmp/openclaw/openclaw-2026-03-16.log` to see if new config was picked up
2. Send a test message on Telegram and check logs for "sendMessage ok"
3. Monitor over next few hours for polling stalls