Summary

The Slack channel can still fail to start with App is not a constructor on self-hosted Linux installs even after #1208 fixed the earlier @slack/bolt interop case from #1209.

Affected versions

• v2026.3.8
• v2026.3.11

What I observed

On a VPS running the gateway as:

node dist/entry.js gateway --port 18789

the service itself stayed alive, but the Slack provider kept crashing and restarting with backoff:

• 2026-03-14T12:34:07.835+03:00 [slack] [default] channel exited: App is not a constructor

After applying the patch from the linked draft PR locally, rebuilding, and restarting the same service, the host switched to:

• 2026-03-14T12:34:51.728+03:00 [slack] socket mode connected

Root cause

The current fallback still assumes that the resolved @slack/bolt value is either:

1. a namespace/module-like object with App and HTTPReceiver, or
2. a default export that itself contains a module-like object.

There is still one runtime/bundler shape where the default import is the App constructor function itself, while HTTPReceiver only exists on the namespace import. In that case the current code falls back to the function value, destructures { App, HTTPReceiver } from it, and new App() later throws App is not a constructor.

Proposed fix

• Resolve Slack Bolt exports from all observed shapes:
  • namespace object
  • nested default module object
  • default import that is already the App constructor
  • namespace fallback
• Add a regression test that covers the constructor-shaped default export explicitly.

Prior context

• Previous report: Slack plugin crashes on startup: 'App is not a constructor' #1209
• Earlier merged fix: fix(slack): handle bolt import for CJS/ESM compatibility #1208

That earlier fix appears to have solved one interop shape, but not this constructor-shaped default export case.