Bolt + Flask + Kubernetes inevitably starts throwing WebSocketConnectionClosedException
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 22/100
- Issue-Typ
- Bug
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Bereich
- backend, devops, networking
Rechercherichtung
Beginne mit app.py und slack_app/slack_service.py und untersuche anschließend SocketModeHandler sowie den im Bericht gezeigten Gunicorn-Befehl. Reproduziere das Verhalten im Kubernetes-Container mit den aufgeführten Versionen von slack-bolt, slack-sdk, websocket-client und Python oder vergleiche es damit, wobei der Fokus auf den wiederkehrenden WebSocketConnectionClosedException-Logs liegt. Als abgeschlossen gilt die Aufgabe, wenn festgestellt wurde, ob der Fehler aus der Deployment-Umgebung oder der Behandlung von Reconnects stammt, und die erforderliche Konfiguration oder Codeänderung dokumentiert wurde.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.)
- Vorherrschende Sprache
- Python
- Sterne
- 1.3k
- Forks
- 288
- Ø Merge
- 1 T. 8 Std.
- Gemergte PRs (30 T.)
- 10
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus slackapi/bolt-python
-
docs enhancement server-side
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
slackapi/bolt-python#1576 · 1 Kommentar ·
-
auto-triage-skip bug security semver:major
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
slackapi/bolt-python#1447 · 9 Kommentare ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 65/100
slackapi/bolt-python#1577 ·
-
area:async auto-triage-skip dependencies
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 65/100
slackapi/bolt-python#1472 · 1 Kommentar · 1 Reaktion ·
-
auto-triage-skip enhancement
slackapi/bolt-python#1346 · 2 Kommentare · 1 zugewiesene Person ·
Alle Issues in slackapi/bolt-python
Ähnliche Issues
-
essnmx good first issue
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 95/100
-
[Feature] 奇物选择添加优先级 Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
syfoud/Simulated_Scepter#174 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Giskard-AI/giskard-oss#2840 · 1 Kommentar ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Offenarea: repo bug perceived difficulty: 2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
yeti-platform/yeti#1380 ·