Allow control over session resume / sequence number tracking.

[mjpowersjr]

use case I would like the ability to manually track session / sequence numbers, and have a mechanism to manually resume a connection. This would allow our service to push updates that require restarting our bots, without possibly missing messages sent during our upgrade process. This feature would also be helpful when recovering from a crash.

ideal solution Provide events that allow us to track session id / sequence numbers (this may already exist?). In addition provide a way to manually provide these numbers during the client login process.

[kevinbioj]

You can already track these with the raw event. For the session ID and sequence number, this code would be okay:

<Client>.on('raw', (packet) => {
  if (packet.op === 0) {
    // do something with packet.s for sequence number
    if (packet.t === 'READY') {
      // do something with packet.d.session_id for the session ID
    }
  }
});

However, why not enabling manual control of the connection... I leave that for other people.

[mjpowersjr]

@Keke27210 Thanks for the quick response! Your example seems perfect for tracking state, hopefully exposing more control over the connection is a reasonable feature request for the project. :-)

[michaelvillar]

Ping on this! Would love this.

[didinele]

In essence, you can fully accomplish this with current-day /ws. discord.js doesn't support it to a full extent as of this major version (v14), but will as of the next one. See https://discord.js.org/docs/packages/ws/main/OptionalWebSocketManagerOptions:Interface#retrieveSessionInfo

[airhorns]

Is there a way to pass in options that make it down to the ws package such that we can still use all the goodness of the top level client while still able to hook into that callback? The workaround above seems to work great for tracking the sequence number etc over time, but I can't find a way to pass it back in upon restart such that the client will resume in a different process.

[didinele]

Yes, you just keep the data in a remote store like Redis.

[airhorns]

I get that -- I'm asking how I can actually retrieve it from redis and pass it back down to the websocket manager today when using the nice high level Client object. No point in storing it if you can't make use of it on the next boot. As far as I can tell, the functions you are talking about are not controllable from userland when using the client: https://github.com/discordjs/discord.js/blob/b2970bb2dddf70d2d918fda825059315f35d23f3/packages/discord.js/src/client/websocket/WebSocketManager.js#L152-L155 . Is there some way to re-create our own version of all the shard manager and websocket shard objects to pre-populate the session info cache on them or something like that?

[didinele]

I think I addressed that in my original comment.

discord.js doesn't support it to a full extent as of this major version (v14), but will as of the next one.

There's no "proper" way to do this at this time.

[airhorns]

Is there a sneaky or hacky way? Just looking for any workaround in the meantime while you folks plan out the nice way at a leisurely pace!