-
Notifications
You must be signed in to change notification settings - Fork 218
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
too_many_websockets disconnect being raised in a single-instance app #1223
Comments
Seems might be caused by #1206 |
Because this is a single instance of an app, this leads me to believe maybe this library is establishing more than these ten connections at a time, possibly due to reconnection logic? Looking at the socket-mode code, it seems to me no connection pool is used in this library. The only location I see where possibly multiple connections are held at the same time is here, but presumably the 'old' session is only active for a very short, overlapping time between the 'new' session is connected, so I'm not sure this is possible. @dbudim are you able to provide more logs? If possible including verbose logging and from the very first occurrence of any disconnect or warning received from the Slack backend. Another possibility is perhaps the backend's state-tracking for how many concurrent connections per app ID are active is stale? |
I'll do on another fail, old logs wasn't saved from beginning. DEBUG log level is ok? Or need more verbose (trace) ? Could we don't check sessions count before waiting next failure? |
Yes, DEBUG level is fine, thank you!
Possible. Once we have logs, I think it will be easier to cross-reference behaviour with code to get a better idea of why this is happening. |
👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized. |
As this issue has been inactive for more than one month, we will be closing it. Thank you to all the participants! If you would like to raise a related issue, please create a new issue which includes your specific details and references this issue number. |
@filmaj Hi, sorry for a delay, I have a full portion of logs from a beginning and it starts from
|
Updated bolt sdk and jdk (saw advices that solves some issues with ssl) but didn't help. First we hav and hadhsake error and then retries and exceeding a limit
|
Hey @dbudim, happy new year! Regarding your last logs provided in your last comment: it seems the websocket connection gets closed 'abnormally' first:
This is assuming that session id: According to the WebSocket spec, an abnormal closure is one where the connection was severed without an endpoint sending a Close frame (see close code 1006). This indicates to me that the underlying network connection had an issue. Regardless, I would expect this SDK to be able to handle this, try to reconnect, and not get itself all confused and cause a rate limit exception 😓 Looking through the logs, it seems to me that possibly the SDK is not accounting for the retries in a correct manner. Some of the session IDs are not 'paired' properly with a open and close message. For example, session ID This will probably be difficult to debug / reproduce, but I will try... |
Actually, #1256 has very similar logging as here... looking into it. |
Operating context:
Relevant logs:
java SDK:
Originally posted by @dbudim in slackapi/node-slack-sdk#1654 (comment)
The text was updated successfully, but these errors were encountered: