slack-sdk is declared without the [socket-mode] extra, so Socket Mode works only while aiohttp arrives transitively #1352

What breaks

Nothing today, which is the point of filing it.

backend/pyproject.toml:121 declares slack-sdk>=3.35.0 without the
[socket-mode] extra, while backend/app/services/channels/slack.py:360
imports:

from slack_sdk.socket_mode.aiohttp import SocketModeClient

That module needs aiohttp, which the extra is what pulls in. It resolves right
now only because something else in the tree brings aiohttp transitively —
verified in the current venv:

$ uv run python -c "import importlib.util as u; print(bool(u.find_spec('aiohttp')))"
True

Why it matters

The day that transitive dependency goes — a bump, a dropped dependency, a
different resolution in the image — Socket Mode raises ImportError at runtime.
The import sits inside a try/except ImportError that turns it into
ChannelNotConfigured, so the failure surfaces as the bot quietly not starting
(see #1351, which is about exactly that being invisible), not as a build error.

And no test would catch it: the guarded import means the suite passes with or
without aiohttp installed.

How you would know it was fixed

slack-sdk[socket-mode] in the manifest, so the dependency Socket Mode needs is
declared by the thing that needs it. Optionally a check that
slack_sdk.socket_mode.aiohttp imports, so a future removal fails in CI rather
than in somebody's Slack workspace.

Related

Cluster Channels and bots in #168; #1351 is the issue about this class of
failure being silent, and #33 is the small-items bag this could equally have
been a checkbox on. Not a duplicate; searched slack-sdk, socket-mode extra.

Pre-existing. Found reading the Socket Mode path while setting a Slack bot up.