Missing upstream capability — documented non-parity.
Current state
Python Discord adapter is HTTP Interactions-only: relies on Discord's webhook delivery of interaction events. For events Discord only emits over the Gateway (persistent WebSocket) — regular channel messages, typing starts, presence updates — Python requires the consumer to run a separate Node.js listener and forward events via webhook with an `x-discord-gateway-token` header.
Upstream TS supports both HTTP Interactions and native Gateway WebSocket connections.
References:
- `src/chat_sdk/adapters/discord/adapter.py:1-10`
- `vercel-chat/packages/adapter-discord/src/index.ts:42-47`
- Already listed under "Known non-parity" in `docs/UPSTREAM_SYNC.md`
Why it matters
- Regular channel messages: Discord sends `MESSAGE_CREATE` over Gateway, not HTTP. Consumers wanting a `on_message` handler for regular (non-slash, non-button) messages need Gateway.
- Typing indicators, presence, reactions on old messages: Gateway-only events.
- Cold starts: persistent Gateway is incompatible with serverless, which is why the Python design chose HTTP-only. But for hosts like VPS/container deploys, Gateway is the natural fit.
Options
Option A — Gateway WebSocket client in adapter
Implement `discord.gateway` connection in the adapter:
- `websockets` library for the socket
- IDENTIFY handshake + heartbeat loop
- Dispatch `MESSAGE_CREATE`, `TYPING_START`, etc. through existing `process_message` path
- Opt-in via config (`DiscordAdapterConfig(mode="gateway" | "http" | "auto")`)
Option B — Keep forwarder pattern, document better
Document the external Gateway forwarder as the canonical deployment for consumers who need Gateway events. Add an example forwarder (small Node script or similar) in a new `examples/discord-gateway-forwarder/` directory.
Recommendation
Option B for now — serverless is the target. Option A is a significant addition (persistent connection management, reconnect logic, shard handling for large bots). Revisit if a consumer needs it.
Acceptance
At minimum:
Missing upstream capability — documented non-parity.
Current state
Python Discord adapter is HTTP Interactions-only: relies on Discord's webhook delivery of interaction events. For events Discord only emits over the Gateway (persistent WebSocket) — regular channel messages, typing starts, presence updates — Python requires the consumer to run a separate Node.js listener and forward events via webhook with an `x-discord-gateway-token` header.
Upstream TS supports both HTTP Interactions and native Gateway WebSocket connections.
References:
Why it matters
Options
Option A — Gateway WebSocket client in adapter
Implement `discord.gateway` connection in the adapter:
Option B — Keep forwarder pattern, document better
Document the external Gateway forwarder as the canonical deployment for consumers who need Gateway events. Add an example forwarder (small Node script or similar) in a new `examples/discord-gateway-forwarder/` directory.
Recommendation
Option B for now — serverless is the target. Option A is a significant addition (persistent connection management, reconnect logic, shard handling for large bots). Revisit if a consumer needs it.
Acceptance
At minimum: