Bolt + Flask + Kubernetes inevitably starts throwing WebSocketConnectionClosedException
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 22/100
- Issue 類型
- 缺陷
- 描述清晰度
- 需要釐清
- 活躍度
- 停滯
- 領域
- backend, devops, networking
研究方向
先從 app.py 和 slack_app/slack_service.py 開始,接著檢查 SocketModeHandler 以及報告中顯示的 Gunicorn 命令。使用所列出的 slack-bolt、slack-sdk、websocket-client 和 Python 版本,在 Kubernetes 容器中重現或比較該行為,重點關注反覆出現的 WebSocketConnectionClosedException 日誌。完成的標準是確認故障來自部署環境還是重新連線處理,並記錄所需的設定或程式碼變更。
由索引模型根據 Issue 內容生成。
描述
Running a bolt app using socket mode inside Flask inside kubernetes works initially but eventually always loses the connection and falls back to a WebSocketConnectionClosedException error.
Given that auto_reconnect_enabled defaults to True, I would expect any failures to just result in the app reconnecting.
I'm opening this as a question as I'm highly doubtful its an actual bug, and instead just something I need to do differently/better in my own app code.
Reproducible in:
The slack_bolt version
slack-bolt = "1.6.0"
slack-sdk = "3.8.0"
websocket-client = "1.1.0"
Python runtime version
python3.7
OS info
Problem is seen running in a container.
Steps to reproduce:
I've tried to emulate the pattern in #255 for running bolt + slack, so a simplified version of my app looks like this:
# ./app.py
from flask import Flask
from slack_app.slack_service import slack
slack.connect()
app = Flask(__name__)
# ./slack_app/slack_service.py
from slack_bolt import App
from slack_bolt.error import BoltUnhandledRequestError
from slack_bolt.adapter.socket_mode.websocket_client import SocketModeHandler
SLACK_APP_TOKEN, SLACK_BOT_TOKEN = get_slack_tokens_from_env()
app = App(
token=SLACK_BOT_TOKEN,
raise_error_for_unhandled_request=True,
)
slack = SocketModeHandler(app, SLACK_APP_TOKEN)
@app.error
def handle_errors(error):
if isinstance(error, BoltUnhandledRequestError):
pass
else:
logger.error(error)
I doubt the BoltUnhandledRequestError is causing this but included it in my example code just in case.
Maybe of note is that i'm using websocket_client based on the suggestion in https://github.com/slackapi/python-slack-sdk/issues/1024. We were seeing the same BlockingIOError logs.
Also maybe of note is that in #255 you suggest using two threads for gunicorn and we are just currently running with:
gunicorn app:app --workers=1 --bind=0.0.0.0:8080 --timeout=3600
Lastly of note is that I am unable to repro this problem locally, and I'm just seeing it inside of our kubernetes cluster. Unfortunately I'm not savvy enough to know how to debug whether the k8s infra is causing my problem (although I am simultaneous to filing this issue working with the people who maintain that infra to investigate from that side).
Expected result:
My slack connection doesn't die.
Actual result:
My app connects fine initially, but after some period of time disconnects from slack and the logs quickly degenerate into the following error every 5 seconds:
on_error invoked (error: WebSocketConnectionClosedException, message: Connection to remote host was lost.)
- 主要語言
- Python
- 星號
- 1.3k
- 分支
- 288
- 平均合併
- 1 天 8 小時
- 30 天內合併 PR
- 10
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
slackapi/bolt-python 的其他 Issue
-
docs enhancement server-side
難度 1/5 1 小時以內 新手友好度 88/100
slackapi/bolt-python#1576 · 1 則留言 ·
-
auto-triage-skip bug security semver:major
難度 2/5 1-3 小時 新手友好度 72/100
slackapi/bolt-python#1447 · 9 則留言 ·
-
難度 3/5 1-2 天 新手友好度 65/100
slackapi/bolt-python#1577 ·
-
area:async auto-triage-skip dependencies
難度 3/5 1-2 天 新手友好度 65/100
slackapi/bolt-python#1472 · 1 則留言 · 1 個 reaction ·
-
auto-triage-skip enhancement
slackapi/bolt-python#1346 · 2 則留言 · 已指派 1 人 ·
查看 slackapi/bolt-python 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 75/100
anthropics/skills#1811 · 1 則留言 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
speaches-ai/speaches#678 ·
-
bug
難度 2/5 1-3 小時 新手友好度 75/100
datalayer/mcp-compose#42 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
conda-forge/spacy-feedstock#177 ·
-
難度 2/5 1-3 小時 新手友好度 70/100
UKGovernmentBEIS/inspect_evals#2523 ·