Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Slack file_share events silently dropped after upgrade from 2026.3.31 to 2026.4.5 [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#61850•Fetched 2026-04-08 02:53:34
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
bassboy2kbassboy2k
Participants
bassboy2kbassboy2k
Timeline (top)
cross-referenced ×2

After upgrading from 2026.3.31 to 2026.4.5, all Slack messages containing file/image attachments are silently dropped. Text-only messages continue to work. Rolling back to 2026.3.31 immediately restores file attachment handling.

Error Message

[WARN] socket-mode:SlackWebSocket:N A pong wasn't received from the server before the timeout of 5000ms! [ERROR] socket-mode:SocketModeClient:0 Failed to send a message as the client has no active connection [ERROR] An unhandled error occurred while Bolt processed (type: event_callback, error: Error: Failed to send a WebSocket message as the client is not ready)

Root Cause

The pong timeout warnings (5000ms) also occur on 2026.3.31 (~95/day on our box), but on that version they never cause event_callback failures — events are acknowledged successfully despite the keepalive hiccups.

On 2026.4.5, file_share events consistently trigger the failure sequence. Text-only messages continue to work fine even with pong timeouts occurring. This suggests the media download path (resolveSlackMedia → fetchRemoteMedia → saveMediaBuffer) introduced enough additional event loop blocking in 2026.4.x to push the total processing time past the pong deadline window.

The code path in prepare-D5Swazfl.js:

const media = await resolveSlackMedia({
    files: ownFiles,
    token: params.botToken,
    maxBytes: params.mediaMaxBytes
});

This await chain (HTTP download + buffer save) runs synchronously in the event handler, blocking the event loop and preventing the Socket Mode client from responding to WebSocket pings.

Fix Action

Workaround

Roll back to 2026.3.31.

PR fix notes

PR #1: fix(slack): reliably ingest Slack file images instead of filename placeholders

Description (problem / solution / changelog)

Summary

Fixes Slack inbound file/image ingestion regressions end-to-end (including Errol runtime validation):

  • Use files.info hydration when Slack events include file id without usable download URLs.
  • Use the correct media-read token path (userToken fallback) in monitor context, so file reads are not restricted to bot-token-only paths.
  • Harden Slack media fetch init handling to avoid passing incompatible fetch guard hook options into Node fetch, which caused silent download failure + filename-only placeholders.
  • Ensure staged inbound media filenames are unique across turns to avoid cross-turn collisions.
  • Add regression tests for id-only payload hydration and sandbox media staging collisions.

Validation

  • pnpm vitest extensions/slack/src/monitor/media.test.ts --run
  • pnpm vitest extensions/slack/src/monitor/message-handler/prepare.test.ts --run
  • pnpm vitest extensions/slack/src/monitor/message-handler/prepare-thread-context.test.ts --run
  • pnpm vitest src/auto-reply/reply.triggers.trigger-handling.stages-inbound-media-into-sandbox-workspace.test.ts --run
  • Live Errol Docker verification in Slack thread: image content now resolved (not placeholder-only filename).

AI assistance

This PR was AI-assisted (Hedwig/OpenClaw + Codex) and then validated with targeted tests and live runtime verification.

Related Slack file issues (tagging all matches)

Refs #50129 Refs #51050 Refs #62088 Refs #51458 Refs #62623 Refs #62551 Refs #61862 Refs #41657 Refs #45574 Refs #61850 Refs #36507 Refs #13634 Refs #44544 Refs #38457 Refs #47600 Refs #56508 Refs #52962 Refs #18426 Refs #62218 Refs #33368 Refs #15087 Refs #18642 Refs #7536 Refs #24681 Refs #23349 Refs #29304 Refs #7110 Refs #13740 Refs #15190 Refs #3595 Refs #3519 Refs #14258 Refs #6008

Changed files

  • extensions/slack/src/monitor/context.ts (modified, +3/-0)
  • extensions/slack/src/monitor/media.test.ts (modified, +58/-1)
  • extensions/slack/src/monitor/media.ts (modified, +84/-18)
  • extensions/slack/src/monitor/message-handler/prepare-thread-context.test.ts (modified, +109/-0)
  • extensions/slack/src/monitor/message-handler/prepare-thread-context.ts (modified, +30/-11)
  • extensions/slack/src/monitor/message-handler/prepare.ts (modified, +1/-1)
  • extensions/slack/src/monitor/monitor.media.test.ts (modified, +41/-2)
  • extensions/slack/src/monitor/provider.ts (modified, +1/-0)
  • src/auto-reply/reply.triggers.trigger-handling.stages-inbound-media-into-sandbox-workspace.test.ts (modified, +42/-6)
  • src/auto-reply/reply/stage-sandbox-media.ts (modified, +11/-4)

PR #62792: Fix Slack file access in channels and DMs

Description (problem / solution / changelog)

  • Tooling note: AI-assisted development (Hedwig/OpenClaw + Codex), with human validation and final review by @armsteadj1.

Summary

Describe the problem and fix in 2–5 bullets:

If this PR fixes a plugin beta-release blocker, title it fix(<plugin-id>): beta blocker - <summary> and link the matching Beta blocker: <plugin-name> - <summary> issue labeled beta-blocker. Contributors cannot label PRs, so the title is the PR-side signal for maintainers and automation.

  • Problem: Slack inbound image/file messages sometimes reached the model as filename placeholders only ([Slack file: IMG_4935.jpg]) instead of actual media content.
  • Why it matters: Image understanding and downstream workflows fail, causing repeated user retries and broken Slack UX.
  • What changed: Fixes the reproduced Slack filename-placeholder regression in this media ingestion path by hardening Slack media hydration/fetch, using the resolved media-read token path, and preventing cross-turn staged filename collisions.
  • What did NOT change (scope boundary): No UI changes, no outbound Slack behavior changes, and no claim that every historical Slack-file issue is resolved.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #50129
  • Related #51050
  • Related #51458
  • Related #62088
  • This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause: Slack file events can arrive with partial metadata and restricted URL access semantics; combined with brittle media fetch init handling and token-read path selection, the ingestion path sometimes failed and fell back to filename placeholders.
  • Missing detection / guardrail: Tests did not lock in this specific Slack file metadata/token-read + staged-media collision path.
  • Contributing context (if known): Threaded Slack flows with repeated filenames and file payload variation increased failure probability.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file:
    • extensions/slack/src/monitor/media.test.ts
    • extensions/slack/src/monitor/message-handler/prepare.test.ts
    • extensions/slack/src/monitor/message-handler/prepare-thread-context.test.ts
    • src/auto-reply/reply.triggers.trigger-handling.stages-inbound-media-into-sandbox-workspace.test.ts
  • Scenario the test should lock in: Slack file events with partial metadata still produce real media payloads, and repeated inbound basenames across turns do not collide.
  • Why this is the smallest reliable guardrail: It exercises the failing boundary directly without requiring a full external Slack E2E harness.
  • Existing test that already covers this (if any): Existing Slack media/prepare coverage exists; this PR extends edge-path coverage.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

List user-visible changes (including defaults/config). If none, write None.

Slack image/file messages now resolve as actual media content more reliably in the affected ingestion path instead of filename-only placeholders.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

Before:
[Slack file event] -> [media fetch/hydration path fails] -> [placeholder only]

After:
[Slack file event] -> [robust hydration + read-token path + safe fetch init] -> [media staged] -> [model sees image]New permissions/capabilities? (No)Secrets/tokens handling changed? (Yes)New/changed network calls? (No)Command/tool execution surface changed? (No)Data access scope changed? (No)If any Yes, explain risk + mitigation:Risk: token selection for Slack media reads changed in this path.Mitigation: constrained to existing configured Slack token sources and media-read flow only; no new secret source or broader access added.OS: macOS host + Docker runtimeRuntime/container: Errol gateway in Docker (openclaw:local)Model/provider: openai-codex/gpt-5.3-codex (Errol runtime default)Integration/channel (if any): Slack (threaded channel flow)Relevant config (redacted): Slack bot/app tokens configured; Errol isolated config/workspace/port.Send Slack thread message with attached image (same repro case where response only saw filename placeholder).Observe pre-fix behavior (placeholder-only).Apply fix branch, rebuild/restart Errol, resend same image flow.Assistant can access and reason over actual image content.Before: placeholder-only behavior reproduced.After: image content was successfully resolved and identified.Attach at least one:Failing test/log before + passing afterTrace/log snippetsScreenshot/recordingPerf numbers (if relevant)What you personally verified (not just CI), and how:Verified scenarios:Reproduced filename-placeholder failure in live Slack thread.Verified post-fix behavior resolved actual image content in same thread flow.Edge cases checked:Slack file metadata hydration path.Repeated inbound basename staging across turns.What you did not verify:Broad claim across all historical Slack-file issues.Full multi-workspace/perf matrix beyond this runtime path.I replied to or resolved every bot review conversation I addressed in this PR.I left unresolved only the conversations that still need reviewer or maintainer judgment.If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.Backward compatible? (Yes)Config/env changes? (No)Migration needed? (No)If yes, exact upgrade steps:List only real risks for this PR. Add/remove entries as needed. If none, write None.Risk:Slack tenant/app-specific file payload variance may expose additional untested edge cases.Mitigation:Coverage added for the reproduced edge path and constrained changes to Slack media ingestion only.Risk:Token-read path change could behave differently in uncommon token setups.Mitigation:Uses existing resolved read-token path with fallback; no new token source introduced.

## Changed files

- `extensions/slack/src/monitor/context.ts` (modified, +3/-0)
- `extensions/slack/src/monitor/media.test.ts` (modified, +173/-0)
- `extensions/slack/src/monitor/media.ts` (modified, +204/-36)
- `extensions/slack/src/monitor/message-handler/prepare-content.ts` (modified, +3/-0)
- `extensions/slack/src/monitor/message-handler/prepare-thread-context.test.ts` (modified, +109/-0)
- `extensions/slack/src/monitor/message-handler/prepare-thread-context.ts` (modified, +37/-11)
- `extensions/slack/src/monitor/message-handler/prepare.ts` (modified, +2/-0)
- `extensions/slack/src/monitor/monitor.media.test.ts` (modified, +41/-2)
- `extensions/slack/src/monitor/provider.ts` (modified, +1/-0)
- `src/auto-reply/reply.triggers.trigger-handling.stages-inbound-media-into-sandbox-workspace.test.ts` (modified, +66/-6)
- `src/auto-reply/reply/stage-sandbox-media.ts` (modified, +39/-4)
- `src/commands/agent-via-gateway.test.ts` (modified, +25/-26)

Code Example

[WARN]  socket-mode:SlackWebSocket:N A pong wasn't received from the server before the timeout of 5000ms!
[ERROR] socket-mode:SocketModeClient:0 Failed to send a message as the client has no active connection
[ERROR] An unhandled error occurred while Bolt processed (type: event_callback, error: Error: Failed to send a WebSocket message as the client is not ready)

---

const media = await resolveSlackMedia({
    files: ownFiles,
    token: params.botToken,
    maxBytes: params.mediaMaxBytes
});
RAW_BUFFERClick to expand / collapse

Summary

After upgrading from 2026.3.31 to 2026.4.5, all Slack messages containing file/image attachments are silently dropped. Text-only messages continue to work. Rolling back to 2026.3.31 immediately restores file attachment handling.

Environment

  • OS: Ubuntu 24.04, DigitalOcean droplet (4 vCPU / 8GB RAM)
  • Node: 22.22.0
  • OpenClaw: 2026.4.5 (3e72c03) — regression. 2026.3.31 (213a704) — working.
  • Slack: Socket Mode, two accounts (default + secondary via channels.slack.accounts)
  • Config: imageModel set to anthropic/claude-sonnet-4-6 with claude-opus-4-6 fallback

Steps to Reproduce

  1. Start on 2026.3.31 — send an image to the bot via Slack DM → agent receives and processes the image ✅
  2. Upgrade to 2026.4.5 (npm install -g openclaw@latest)
  3. Run openclaw doctor --fix, restart gateway
  4. Send an image to the bot via Slack DM → agent receives only [Slack file: filename.png] placeholder text, no image data. The event itself often fails entirely with the errors below.
  5. Downgrade back to 2026.3.31 → image handling works again immediately ✅

Error Logs

Every file_share event triggers this sequence:

[WARN]  socket-mode:SlackWebSocket:N A pong wasn't received from the server before the timeout of 5000ms!
[ERROR] socket-mode:SocketModeClient:0 Failed to send a message as the client has no active connection
[ERROR] An unhandled error occurred while Bolt processed (type: event_callback, error: Error: Failed to send a WebSocket message as the client is not ready)

The pong timeout kills the WebSocket connection before the event acknowledgment is sent, so the message is silently lost. Slack retries briefly but hits the same pattern.

Analysis

The pong timeout warnings (5000ms) also occur on 2026.3.31 (~95/day on our box), but on that version they never cause event_callback failures — events are acknowledged successfully despite the keepalive hiccups.

On 2026.4.5, file_share events consistently trigger the failure sequence. Text-only messages continue to work fine even with pong timeouts occurring. This suggests the media download path (resolveSlackMedia → fetchRemoteMedia → saveMediaBuffer) introduced enough additional event loop blocking in 2026.4.x to push the total processing time past the pong deadline window.

The code path in prepare-D5Swazfl.js:

const media = await resolveSlackMedia({
    files: ownFiles,
    token: params.botToken,
    maxBytes: params.mediaMaxBytes
});

This await chain (HTTP download + buffer save) runs synchronously in the event handler, blocking the event loop and preventing the Socket Mode client from responding to WebSocket pings.

Related Issues

  • #58519 — Event loop starvation causes pong timeouts and silent message loss (same root cause, general case)
  • #14248 — Feature request to expose clientPingTimeout for Socket Mode
  • #41473 — Community PR to add channels.slack.socketMode.clientPingTimeout config (unmerged)
  • #57864 — Same pattern on Discord: media attachment download blocks inbound worker

Suggested Fix

Short-term: merge #41473 (expose clientPingTimeout config) so users can raise the 5000ms default.

Long-term: run the media download outside the event acknowledgment path — acknowledge the event immediately, then download/process the media asynchronously. This is what #58519 suggests with worker_threads for keepalive, but even just deferring the download after ack() would fix this specific regression.

Workaround

Roll back to 2026.3.31.

extent analysis

TL;DR

  • The most likely fix is to merge the community PR #41473 to expose the clientPingTimeout config, allowing users to raise the default 5000ms timeout.

Guidance

  • Identify the root cause of the issue: the media download path introduced in 2026.4.x is blocking the event loop, causing pong timeouts and silent message loss.
  • Consider merging PR #41473 to expose the clientPingTimeout config, allowing for a temporary increase in the timeout value.
  • As a long-term solution, refactor the media download to run outside the event acknowledgment path, acknowledging the event immediately and then downloading/processing the media asynchronously.
  • Verify the fix by testing file attachment handling after applying the suggested changes.

Example

  • No code snippet is provided as the issue already includes a suggested fix and the code path causing the issue.

Notes

  • The suggested fix may not be applicable if the underlying issue is not solely related to the clientPingTimeout value.
  • The long-term solution requires significant changes to the media download handling and may require additional testing and verification.

Recommendation

  • Apply the workaround by rolling back to 2026.3.31 until a permanent fix is available, as this version is known to work correctly with file attachments.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#retriever error#indexing error#inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING