Optional components

Deploy the message gateway

Deploy the shared Feishu and Slack message gateway and verify instance heartbeats, channel connections, and actual replies.

Deployment guide · Module: deploy · Administrators · Deployment: Private deployment · Confirmed product versions: Not specified · Source: Existing documentation

The message gateway maintains Feishu and Slack platform connections and translates messages between the platforms and the AskTable backend. The image and service name remain asktable-feishu-gateway; the same service handles both platforms. It contains no Agent logic and communicates with the main service through Redis. Add it separately for private deployment; it is unnecessary if you do not use message channels.

The main service and gateway must use versions released together. When the channel protocol changes, upgrade both at the same time, rather than updating only one.

Prerequisites

Item	Requirement
Basic deployment	Running after following Private deployment (Docker), with `asktable-redis` running
Platform app	For Feishu, prepare an App ID and App Secret and enable persistent connections and message-receiving events; for Slack, prepare a Bot Token and App Token and enable Socket Mode
Data	The project already has a usable data source and data Agent
Authorization scope	Confirm which members or departments may access the Agent

See Connect a Feishu bot or Connect a Slack bot for platform app creation, permission requests, and publication steps.

Steps

Add the gateway service

Add this service to docker-compose.yaml:

services:
  # Message gateway: shared by Feishu and Slack
  asktable-feishu-gateway:
    image: registry.cn-shanghai.aliyuncs.com/datamini/asktable-feishu-gateway:latest
    container_name: asktable-feishu-gateway
    restart: unless-stopped
    depends_on:
      - asktable-redis
    environment:
      REDIS_URL: redis://asktable-redis:6379

It shares the main service's asktable-redis; do not add ports.

Start the service

docker compose up -d asktable-feishu-gateway

Confirm gateway heartbeats are written to Redis

docker compose exec asktable-redis redis-cli hgetall at:channel:health

A gateway:<instance ID> field whose value has status set to ok and a continuously updating timestamp indicates that the gateway process is reporting heartbeats. Heartbeats update every 30 seconds; the server ignores heartbeats older than 75 seconds. A stale field in Redis does not prove that the instance is still online. Heartbeats do not prove that a particular channel is connected.

Select a platform and configure the channel

Open the target data Agent → “Channels” → “Platform”, and select Feishu or Slack. Initial configuration requires the corresponding credentials to be entered and saved; the platform is enabled only after success. Canceling keeps the previous platform.

Platform	Credentials
Feishu	App ID and App Secret are required; Encrypt Key and Verification Token are optional according to the app configuration
Slack	Bot Token (`xoxb-`) and App Token (`xapp-`) are required

Check “Connection status”, then send a test question. Status refreshes every 5 seconds; “Details” under “Recent messages” shows processing and reply delivery results separately.

Verify with a real question

Have an authorized member ask the bot a question in a direct message, then add the bot to a test group or channel and mention it with @ to ask a question. Confirm a correct reply and that the results respect the member's data permissions. Evaluate instance heartbeats, successful connections, completed analysis, and successful reply delivery separately.

Key constraints

Item	Value or default	Where to change it
Communication	Redis only; the gateway does not listen on a host port	Do not add `ports` to `asktable-feishu-gateway`
`REDIS_URL`	`redis://asktable-redis:6379`; must match the main service	Gateway `environment`
Instance heartbeat	Writes `gateway:<instance ID>` to `at:channel:health` every 30 seconds	Used only to determine whether the gateway instance is active
Individual channel status	`<platform>:channel:<channel ID>:<instance ID>`; the corresponding instance heartbeat must be valid and the configuration version must match	Agent → “Channels” → “Connection status”
Channel credentials	Stored in the AskTable backend and pushed to the gateway through Redis; do not put App IDs in gateway environment variables	Agent → “Channels” → “Credential configuration”
Channel preferences	Empty by default; at most 1024 characters	Agent → “Channels” → “General configuration”
Deep reasoning	Off by default, using fast mode	Agent → “Channels” → “General configuration”
Conversation continuity	Direct messages and top-level Q&A reuse a conversation for the same person; a new conversation is created after 24 consecutive hours without new messages. Thread conversations do not expire under this window	A thread accepts only the original questioner; follow-up questions in groups still require `@`
Image version	The example uses `latest`; production deployment uses a gateway image released with the main service	`image` in `docker-compose.yaml`; upgrade the main service and gateway together
Relationship to scheduled reports	Channels are two-way conversations where a user asks and the bot answers; scheduled delivery is separate. See Scheduled analysis reports	—

Troubleshooting

Symptom	How to identify it	Action
Instance heartbeat is not updating	`gateway:<instance ID>` is absent or its timestamp stops updating	Check container status, gateway logs, and Redis connectivity; stale fields do not mean the gateway is still online
Heartbeat is normal but the channel is disconnected	The platform has not been enabled, or individual channel status is missing or credentials are invalid	Check the current platform, connection explanation, and credentials in the Agent's “Channels”; a normal heartbeat does not imply a connected channel
Gateway exits immediately on startup	Logs show a refused Redis connection	Check `REDIS_URL` and confirm `asktable-redis` is running
Connected, but recent messages do not update	The platform did not deliver this question	Check event subscriptions, app publication, whether the bot is in the group or channel, and whether the question mentions it with `@`; test a direct message first
Message processing failed	The processing status in “Recent messages” → “Details” shows a failure	Check data sources and user authorization, then examine main service logs for the specific error
Reply delivery failed	Analysis completed, but reply status shows a failure	Check the bot's sending permissions and target destination; inspect the platform error in gateway logs
A user's question is rejected or awaits approval	The whitelist is enabled, and user binding or Agent authorization is missing	Follow Feishu user permissions or the Slack guide
No new messages after disabling	The current platform is set to “Disabled”	Select the configured platform again; disabling retains credentials and configuration

Next steps

Connect a Feishu bot — Feishu app creation, permissions, and publication
Connect a Slack bot — Socket Mode apps and user authorization
Set data access scopes — People, roles, and Agent whitelists
Deploy AI Search (value indexing) — Match full values from abbreviated questions in Feishu
Private deployment (Docker) — Main service deployment and troubleshooting

Documentation feedback

Docs assistant

What would you like to know?