openclaw - 💡(How to fix) Fix [Bug]: Slack WebClient path intermittently fails with `EAI_AGAIN slack.com` even when host DNS and Node HTTPS are healthy [1 comments, 1 participants]

Summary

On OpenClaw 2026.4.14, Slack delivery can fail intermittently with:

Error: A request error occurred: getaddrinfo EAI_AGAIN slack.com

In this case the gateway does not crash-loop. The process stays up, but Slack sends fail and Socket Mode also shows repeated pong timeouts / stale-socket restarts.

The key detail is that host-level DNS and host-level Node networking appear healthy on the same machine:

• getent ahosts slack.com succeeds
• host Python socket.getaddrinfo('slack.com', 443) succeeds repeatedly
• host Node dns.lookup('slack.com') succeeds repeatedly
• host Node https.get('https://slack.com') succeeds repeatedly

So the failure seems specific to the OpenClaw gateway Slack/WebClient path rather than the machine's general DNS stack.

Related but not identical: #24581

Actual behavior

• Slack direct sends fail intermittently with getaddrinfo EAI_AGAIN slack.com
• Slack Socket Mode logs repeated pong timeouts and stale-socket restarts
• Gateway remains running
• Previously queued Slack delivery retries can accumulate and hit message_limit_exceeded

Observed logs included:

[WARN]  web-api:WebClient:0 http request failed getaddrinfo EAI_AGAIN slack.com
Error: A request error occurred: getaddrinfo EAI_AGAIN slack.com
[WARN]  socket-mode:SlackWebSocket:1 A pong wasn't received from the server before the timeout of 5000ms!
[health-monitor] [slack:default] health-monitor: restarting (reason: stale-socket)

Expected behavior

If host DNS / host Node networking are healthy, Slack sends should not fail with intermittent EAI_AGAIN from inside the gateway path.

At minimum, if this is an intermittent resolver/library issue inside the Slack transport path, the gateway should either:

• recover cleanly without repeated delivery failures, or
• surface more precise diagnostics about which path is actually failing (Slack WebClient, socket-mode reconnect, custom fetch/transport, etc.)

Environment

• OpenClaw: 2026.4.14 (323493f)
• Latest stable currently visible on npm at report time: 2026.4.15
• Node: v22.22.2
• OS: Debian / Raspberry Pi host
• Gateway managed by systemd
• Slack Socket Mode enabled

Gateway service environment is minimal and clean:

• no HTTP_PROXY
• no HTTPS_PROXY
• no NO_PROXY
• no NODE_OPTIONS

What was ruled out locally

1. Slack cron noise / stale delivery queue

• We silenced active noisy Slack cron announcements (delivery.mode: none) to stop creating new pressure.
• We quarantined 11 stale pending Slack delivery entries from ~/.openclaw/delivery-queue so recovery no longer replayed them.
• This removed the recovery storm, but fresh sends still hit EAI_AGAIN.

1. Broken Slack target config

• One unrelated cron job was missing delivery.to; fixing it did not resolve the gateway/WebClient issue.

1. Host DNS / host networking

• resolvectl status looked normal
• /etc/resolv.conf looked normal
• getent ahosts slack.com succeeded
• host Python DNS lookup succeeded repeatedly
• host Node DNS lookup succeeded repeatedly
• host Node HTTPS requests to https://slack.com succeeded repeatedly

1. Gateway runtime environment

• systemd unit and wrapper script were checked
• no resolver/proxy-related env vars were present in the live process
• tried forcing Node --dns-result-order=ipv4first; this did not change the failure mode, so that was reverted

Narrowed suspicion

This looks like a bug or edge case specific to the OpenClaw Slack transport path, or an interaction between the long-running gateway process and the Slack SDK / resolver path, because:

• host-level Node lookups and HTTPS are healthy
• the gateway Slack/WebClient path still reports EAI_AGAIN
• Socket Mode also appears unstable on the same gateway process

Repro notes

This has been observed on a live gateway with Slack configured, but a deterministic repro is not yet isolated.

A possible repro strategy might be:

1. Run gateway with Slack Socket Mode enabled
2. Allow stale Slack delivery retries or repeated Slack sends to build pressure
3. Observe Socket Mode pong timeouts / stale-socket restarts
4. Attempt a fresh direct Slack send through OpenClaw
5. Observe intermittent EAI_AGAIN slack.com from the WebClient path even though host DNS checks still pass

Useful implementation clue

The installed OpenClaw build appears to use a standard Slack WebClient path in the Slack client module, while host-level Node dns.lookup() / https.get() both succeed repeatedly. That mismatch may help narrow where the resolver / transport behavior diverges.

If useful, I can also provide the exact queue entry shape and more sanitized gateway logs from the affected system.