-
Notifications
You must be signed in to change notification settings - Fork 663
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhandled event 'websocket open' in state 'connected'. #1771
Comments
Thanks for the report, I believe this may occur during the brief window when the app is attempting to reconnect, it will have two simultaneous websocket connections open, which may confuse the state machine, as the state machine assumes a single connection exists. I will mark this as a bug and will try to reproduce the scenario using the integration tests. |
Any clue why this error: It doesn't seem to directly affect anything (and I guess it only happens when there are no incoming requests), but still curious. |
What version of the Also, if it is possible to turn on debug logging for your app (it looks like you are using bolt? If so: instructions on how to do so here) and post debug logs, that would be helpful too. I am not sure on the exact cause of the logs, it may also depend on any additional code you may have integrated in your bolt app. Can you post your |
I'm also seeing this trace recently. There're so many reconnection trial, and after that it always said const app = new App({
signingSecret: process.env.SECRET,
token: process.env.TOKEN,
socketMode: true,
appToken: process.env.APP_TOKEN,
port: Number(process.env.PORT || 3000),
logLevel: LogLevel.INFO,
});
app.start(); |
I use This is my app initialization:
|
That should be fine. If there are easily detectable problems with the secrets (like missing or empty values), it would be raised upon initialization. We've had more reports from folks about problems with reconnecting and this package recently. In my investigations, it is partly due to the very old implementation in the node socket-mode package (based on a several-years-old version of the old We are considering migrating the python-slack-sdk implementation/design to node and releasing it as the next major version. |
An RC was released to try to address this: |
The fix has now been released to mainline in 1.3.5 and is out of release candidacy. It will also be present in the soon-to-come 2.0 release of |
Is this fixed and available on
|
The class of bugs "unhandled event X in state Y" is a difficult, intermittent bug in socket-mode 1.x. The underlying issue is in the design of socket-mode 1.x: there is a single state machine for the entire module, but the module sometimes can briefly use more than one WebSocket connection (specifically during reconnections). These multiple WS connections pump state transitions based on WS connection state into the single state machine. This is not an issue when only one WS connection is active, but sometimes during or around reconnection, when two WS connections are briefly active, they can send their own connection event state transitions into the single state machine, which can be contradictory and lead to this issue. Socket-mode 2.0 uses a completely new design that is not susceptible to this class of bugs.
FYI @spencer-melo-lp |
Description
There were a couple of random crashes on my slack bot in the past few days.
Adding the traces below (both are similar, but not identical).
Not really reproducible.
Trace 1:
Trace 2:
Packages:
Select all that apply:
@slack/web-api
@slack/rtm-api
@slack/webhooks
@slack/oauth
@slack/socket-mode
@slack/types
Reproducible in:
The Slack SDK version
"slack/bolt": "^3.13.3"
"slack/logger": "^3.0.0"
"slack/web-api": "^6.9.1"
Node.js runtime version
v16.8.1
OS info
Red Hat Enterprise Linux 8
Steps to reproduce:
The app was running since a long time, and these errors led it to crash (twice in the past few days)
Expected result:
The app should've worked fine.
Actual result:
The app crashed.
Requirements
For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.
The text was updated successfully, but these errors were encountered: