fix(slack): strip SSRF dispatcher from media fetch to prevent undici version conflict#64022
fix(slack): strip SSRF dispatcher from media fetch to prevent undici version conflict#64022mjamiv wants to merge 2 commits intoopenclaw:mainfrom
Conversation
Greptile SummaryThis PR fixes a silent failure in Slack inbound attachment downloads caused by two undici Confidence Score: 5/5Safe to merge — targeted two-line logic change with a matching test update and no side effects on other code paths. The fix is minimal and correct: it strips the upstream dispatcher before delegating (preventing the undici collision) while preserving the routing signal. Both the happy path and the fallback (mocked fetch in tests) remain correct. No other files are affected. No files require special attention. Reviews (1): Last reviewed commit: "fix(slack): strip SSRF dispatcher from S..." | Re-trigger Greptile |
|
Note: this fix also covers the code path addressed by #63401 (stripping cc @martingarramon — your confirmation of the root cause on #63905 matches exactly. The |
|
Cross-link for reviewer context: PR #64766 was merged on 2026-04-11 and touches the same |
…ndici version conflict When `fetchWithSsrFGuard` delegates to `createSlackMediaFetch`, it injects a pinned undici 8.x dispatcher into the `init` object. `createSlackMediaFetch` then spreads `...init` (including that dispatcher) into `fetchWithRuntimeDispatcher`, which creates its own dispatcher. The two dispatchers from different undici versions collide, causing "invalid onRequestStart method" errors that silently drop all inbound Slack attachments. Fix: use the presence of `dispatcher` in `init` as a routing signal (runtime fetch vs global fetch) but strip it before forwarding. This matches the approach taken in openclaw#63984 (BlueBubbles) for the same root cause. Fixes openclaw#63905
The dispatcher-strip fix added 7 lines to createSlackMediaFetch, shifting the three pre-existing fetch() callsites in fetchWithSlackAuth from lines 96/115/120 to 103/122/127.
ff59c9c to
b6cdc58
Compare
|
Codex review: found issues before merge. Summary Reproducibility: yes. The linked Slack report gives concrete container/sandbox steps and Next step before merge Security Review findings
Review detailsBest possible solution: Rebuild from current main and make the Slack media transport contract explicit: either approve a reviewed preflight-only/ Do we have a high-confidence way to reproduce the issue? Yes. The linked Slack report gives concrete container/sandbox steps and Is this the best way to solve the issue? No, not as currently proposed. The source/test change is narrow and has a BlueBubbles precedent, but it silently removes the pinned dispatcher from the final Slack request and the branch carries a stale allowlist update. Full review comments:
Overall correctness: patch is incorrect Security concerns:
Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against f523620abe7f. |
|
Conflict review update:
I am not pushing a refresh from automation because the security decision is still the blocker: this patch strips the SSRF guard's pinned dispatcher from the actual Slack media request. That may be acceptable only if maintainers explicitly approve a Slack-specific preflight-only contract. Otherwise the safer direction is to preserve pinned dispatcher enforcement while fixing the Undici version collision. Recommended next step: maintainer decides the Slack transport contract first; after that, rebuild the PR on current
|
Summary
Fixes #63905 — Slack inbound attachments silently fail with
invalid onRequestStart methodin container/sandbox deployments.Root cause:
fetchWithSsrFGuardinjects a pinned undici 8.xdispatcherinto theinitobject, then delegates tocreateSlackMediaFetch(). That function spreads...init(including the dispatcher) intofetchWithRuntimeDispatcher, which creates its own dispatcher. The two dispatchers from different undici major versions (bundled 8.x vs Node's built-in 7.x) collide, throwing the error. Every Slack attachment download silently fails and the agent only sees placeholder text.Fix: Use the presence of
dispatcherininitas a routing signal (runtime fetch vs global fetch) but strip the dispatcher itself before forwarding. Same pattern as #63984 (BlueBubbles).Changes
extensions/slack/src/monitor/media.ts— Destructuredispatcherout ofinitincreateSlackMediaFetchbefore delegatingextensions/slack/src/monitor/media.test.ts— Update assertion: dispatcher should NOT be forwarded to runtime fetchVerification
Tested on a production OpenClaw v2026.4.9 instance running in an OpenShell sandbox with Slack channel integration. Before the fix, all inbound PDF/image attachments produced only placeholder text. After applying the equivalent patch to the dist bundle (
actions-BsuJQp72.js), attachments download and the agent analyzes full file content with zero fetch errors.