(Describe your issue and goal here)
Goal:
Our goal is to programmatically access crucial information from the hello event sent by Slack upon establishing a Socket Mode connection. Specifically, we need num_connections to implement reliable "double-launch detection" for our application. Additionally, debug_info and connection_info.app_id (as provided in the hello event) would be very useful for enhanced diagnostics and connection verification.
Issue:
The @slack/socket-mode client successfully receives the hello event from Slack. This is evident from the SDK's own DEBUG logs, which show the complete hello payload including num_connections, debug_info, and connection_info.app_id. For example:
[timestamp] DEBUG (slack-socket/pid): Received a message on the WebSocket: {"type":"hello","num_connections":N,"debug_info":{...},"connection_info":{"app_id":"A..."}}
However, despite the SDK receiving this information, its contents (especially num_connections) are not exposed to the SDK user through any readily accessible public API:
This lack of access prevents developers from:
- Using
num_connections to programmatically detect and manage multiple running instances of their Socket Mode application.
- Easily accessing
debug_info or connection_info.app_id (from the hello event context) for application-level logging, diagnostics, or connection verification.
Proposed Solution/Suggestion:
We request that the SocketModeClient expose key information from the hello event. Ideal ways to implement this could be:
- Emit a new, dedicated
hello event with the parsed hello message payload:
client.on('hello', (payload) => {
// payload would be the parsed content of the hello message
// const { num_connections, debug_info, connection_info } = payload;
console.log(`App ${payload.connection_info.app_id} connected. Active connections: ${payload.num_connections}`);
});
- Enhance the
connected event's payload to include the hello payload or selected fields from it.
- Expose relevant
hello data as properties on the SocketModeClient instance after the hello message is processed (e.g., client.numConnections, client.socketDebugInfo, client.socketAppId).
Access to num_connections is the primary motivation, but making debug_info and connection_info also available would greatly benefit developers.
Packages:
Select all that apply:
Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.
Use Case Example / Motivation:
The primary use case is "double-launch detection" . A bot developer wants to ensure only one instance of their Socket Mode bot is running using a specific app-level token. By checking num_connections upon startup, if it's greater than 1, the newly started instance can decide to log a warning, shut itself down gracefully, or enter a standby mode. This helps prevent redundant processing, unexpected behavior, and potential rate limit issues.
Current Limitations / Workarounds:
Currently, this vital information (num_connections, etc., from the hello event) is only visible within the SDK's internal DEBUG logs. Relying on parsing DEBUG logs is not a robust or recommended programmatic approach. Implementing alternative instance tracking mechanisms (e.g., using an external datastore like Redis) adds significant complexity compared to directly utilizing a value that Slack already provides to the client.
Environment:
- Package Version (
@slack/socket-mode): 2.0.4 (as observed in logs, but request applies to current/future versions)
- Node.js Version:
v22.12.0
Additional Context:
The DEBUG logs clearly show the hello message being received internally by the SDK:
[13:11:46.908] DEBUG (slack-socket/80817): Received a message on the WebSocket: {"type":"hello","num_connections":2,"debug_info":{"host":"applink-8",...},"connection_info":{"app_id":"A08SDQ16LUV"}}
The challenge is the absence of a public API to access these details programmatically.
Thank you for considering this feature request. Exposing this information would greatly improve the capabilities for developers building robust and diagnosable applications using Socket Mode.
(Describe your issue and goal here)
Goal:
Our goal is to programmatically access crucial information from the
helloevent sent by Slack upon establishing a Socket Mode connection. Specifically, we neednum_connectionsto implement reliable "double-launch detection" for our application. Additionally,debug_infoandconnection_info.app_id(as provided in thehelloevent) would be very useful for enhanced diagnostics and connection verification.Issue:
The
@slack/socket-modeclient successfully receives thehelloevent from Slack. This is evident from the SDK's own DEBUG logs, which show the completehellopayload includingnum_connections,debug_info, andconnection_info.app_id. For example:[timestamp] DEBUG (slack-socket/pid): Received a message on the WebSocket: {"type":"hello","num_connections":N,"debug_info":{...},"connection_info":{"app_id":"A..."}}However, despite the SDK receiving this information, its contents (especially
num_connections) are not exposed to the SDK user through any readily accessible public API:connectedevent fires, but its payload isundefined(or does not containhellodata).https://github.com/slackapi/node-slack-sdk/blob/main/packages/socket-mode/src/SocketModeClient.ts#L318-L321
This lack of access prevents developers from:
num_connectionsto programmatically detect and manage multiple running instances of their Socket Mode application.debug_infoorconnection_info.app_id(from thehelloevent context) for application-level logging, diagnostics, or connection verification.Proposed Solution/Suggestion:
We request that the
SocketModeClientexpose key information from thehelloevent. Ideal ways to implement this could be:helloevent with the parsedhellomessage payload:connectedevent's payload to include thehellopayload or selected fields from it.hellodata as properties on theSocketModeClientinstance after thehellomessage is processed (e.g.,client.numConnections,client.socketDebugInfo,client.socketAppId).Access to
num_connectionsis the primary motivation, but makingdebug_infoandconnection_infoalso available would greatly benefit developers.Packages:
Select all that apply:
@slack/web-api@slack/rtm-api@slack/webhooks@slack/oauth@slack/socket-mode@slack/typesRequirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.
Use Case Example / Motivation:
The primary use case is "double-launch detection" . A bot developer wants to ensure only one instance of their Socket Mode bot is running using a specific app-level token. By checking
num_connectionsupon startup, if it's greater than 1, the newly started instance can decide to log a warning, shut itself down gracefully, or enter a standby mode. This helps prevent redundant processing, unexpected behavior, and potential rate limit issues.Current Limitations / Workarounds:
Currently, this vital information (
num_connections, etc., from thehelloevent) is only visible within the SDK's internal DEBUG logs. Relying on parsing DEBUG logs is not a robust or recommended programmatic approach. Implementing alternative instance tracking mechanisms (e.g., using an external datastore like Redis) adds significant complexity compared to directly utilizing a value that Slack already provides to the client.Environment:
@slack/socket-mode):2.0.4(as observed in logs, but request applies to current/future versions)v22.12.0Additional Context:
The DEBUG logs clearly show the
hellomessage being received internally by the SDK:[13:11:46.908] DEBUG (slack-socket/80817): Received a message on the WebSocket: {"type":"hello","num_connections":2,"debug_info":{"host":"applink-8",...},"connection_info":{"app_id":"A08SDQ16LUV"}}The challenge is the absence of a public API to access these details programmatically.
Thank you for considering this feature request. Exposing this information would greatly improve the capabilities for developers building robust and diagnosable applications using Socket Mode.