openclaw - ✅(Solved) Fix [BUG] v2026.3.31: handleSlackHttpRequest unconditionally loaded causes HTTP 500 when @slack/web-api is missing [1 pull requests, 1 comments, 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#58994Fetched 2026-04-08 02:30:13
View on GitHub
Comments
1
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
cross-referenced ×1referenced ×1renamed ×1

Error Message

After upgrading from v2026.3.24 to v2026.3.31, all HTTP requests to the gateway return 500 Internal Server Error, including the Control UI dashboard (/chat?session=main, /, /__openclaw__/canvas/, etc.). WebSocket connections continue to work normally. Other stages like control-ui-http are correctly guarded by controlUiEnabled, but the Slack stage has no such guard. When the Slack plugin is disabled (default) and @slack/web-api is not installed, the lazy module load inside handleSlackHttpRequest throws, which is caught by the outer catch block and returned as a generic 500 with no error logging: res.end("Internal Server Error"); 6. Observe: 500 Internal Server Error

  • If a stage fails due to a missing optional dependency, it should log the error and continue to the next stage, not fail the entire request

Root Cause

In createGatewayHttpServer() (src/gateway/server-http.ts), the handleSlackHttpRequest stage is unconditionally added to the HTTP request pipeline:

const requestStages: GatewayHttpRequestStage[] = [
  { name: "hooks", run: () => handleHooksRequest(req, res) },
  // ...
  { name: "slack", run: () => handleSlackHttpRequest(req, res) },  // <-- always included
];

Other stages like control-ui-http are correctly guarded by controlUiEnabled, but the Slack stage has no such guard. When the Slack plugin is disabled (default) and @slack/web-api is not installed, the lazy module load inside handleSlackHttpRequest throws, which is caught by the outer catch block and returned as a generic 500 with no error logging:

} catch {
  res.statusCode = 500;
  res.setHeader("Content-Type", "text/plain; charset=utf-8");
  res.end("Internal Server Error");
}

This makes the issue very hard to diagnose since there are no log entries for the HTTP failure.

Fix Action

Workaround

Install the Slack peer dependencies manually:

cd $(npm root -g)/openclaw
npm install @slack/bolt @slack/web-api --no-save --ignore-scripts

PR fix notes

PR #58999: fix: guard Slack HTTP stage behind channels.slack.enabled

Description (problem / solution / changelog)

Summary

  • Move handleSlackHttpRequest stage behind configSnapshot.channels?.slack?.enabled === true check in createGatewayHttpServer()
  • Prevents HTTP 500 when @slack/web-api is not installed and Slack plugin is disabled (default)
  • Consistent with how other optional stages (Control UI, OpenAI, OpenResponses) are already guarded

Test plan

  • Start gateway without @slack/web-api installed, Slack disabled → HTTP requests should return normally
  • Start gateway with Slack enabled and @slack/web-api installed → Slack HTTP callbacks should continue to work
  • Verify Control UI dashboard loads at http://127.0.0.1:<port>/

Fixes #58994

🤖 Generated with Claude Code

Changed files

  • src/gateway/server-http.ts (modified, +5/-3)

Code Example

const requestStages: GatewayHttpRequestStage[] = [
  { name: "hooks", run: () => handleHooksRequest(req, res) },
  // ...
  { name: "slack", run: () => handleSlackHttpRequest(req, res) },  // <-- always included
];

---

} catch {
  res.statusCode = 500;
  res.setHeader("Content-Type", "text/plain; charset=utf-8");
  res.end("Internal Server Error");
}

---

cd $(npm root -g)/openclaw
npm install @slack/bolt @slack/web-api --no-save --ignore-scripts
RAW_BUFFERClick to expand / collapse

Bug Description

After upgrading from v2026.3.24 to v2026.3.31, all HTTP requests to the gateway return 500 Internal Server Error, including the Control UI dashboard (/chat?session=main, /, /__openclaw__/canvas/, etc.). WebSocket connections continue to work normally.

Root Cause

In createGatewayHttpServer() (src/gateway/server-http.ts), the handleSlackHttpRequest stage is unconditionally added to the HTTP request pipeline:

const requestStages: GatewayHttpRequestStage[] = [
  { name: "hooks", run: () => handleHooksRequest(req, res) },
  // ...
  { name: "slack", run: () => handleSlackHttpRequest(req, res) },  // <-- always included
];

Other stages like control-ui-http are correctly guarded by controlUiEnabled, but the Slack stage has no such guard. When the Slack plugin is disabled (default) and @slack/web-api is not installed, the lazy module load inside handleSlackHttpRequest throws, which is caught by the outer catch block and returned as a generic 500 with no error logging:

} catch {
  res.statusCode = 500;
  res.setHeader("Content-Type", "text/plain; charset=utf-8");
  res.end("Internal Server Error");
}

This makes the issue very hard to diagnose since there are no log entries for the HTTP failure.

Steps to Reproduce

  1. Install openclaw v2026.3.31 globally (npm install -g [email protected])
  2. Do not install @slack/web-api or @slack/bolt (default state)
  3. Keep Slack plugin disabled (default)
  4. Start the gateway: openclaw gateway --port 18789
  5. Access any HTTP endpoint: curl http://127.0.0.1:18789/
  6. Observe: 500 Internal Server Error

Expected Behavior

  • HTTP requests should work normally when Slack is disabled
  • The Slack HTTP stage should be conditionally included only when the Slack plugin/channel is enabled
  • If a stage fails due to a missing optional dependency, it should log the error and continue to the next stage, not fail the entire request

Workaround

Install the Slack peer dependencies manually:

cd $(npm root -g)/openclaw
npm install @slack/bolt @slack/web-api --no-save --ignore-scripts

extent analysis

TL;DR

Conditionally include the Slack HTTP stage in the request pipeline only when the Slack plugin is enabled to prevent the 500 Internal Server Error.

Guidance

  • Verify that the Slack plugin is disabled by default and that the @slack/web-api package is not installed, which triggers the error.
  • To fix the issue, modify the createGatewayHttpServer() function in src/gateway/server-http.ts to conditionally add the handleSlackHttpRequest stage based on the Slack plugin's enabled state.
  • Consider adding error logging for the HTTP failure to improve diagnosability.
  • As a temporary workaround, install the Slack peer dependencies manually using the provided command.

Example

const requestStages: GatewayHttpRequestStage[] = [
  { name: "hooks", run: () => handleHooksRequest(req, res) },
  // ...
  ...(controlUiEnabled ? [{ name: "control-ui-http", run: () => handleControlUiRequest(req, res) }] : []),
  ...(slackPluginEnabled ? [{ name: "slack", run: () => handleSlackHttpRequest(req, res) }] : []),
];

Notes

The provided workaround may not be a permanent solution, as it requires manual installation of dependencies. A more robust fix would involve modifying the code to conditionally include the Slack stage.

Recommendation

Apply the workaround by installing the Slack peer dependencies manually, as this provides a temporary solution to the issue. However, it is recommended to modify the code to conditionally include the Slack stage for a more permanent fix.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING