Resume Sessions After a Restart

"Resuming" is really three different failure modes, each handled at a different layer. They are not alternatives — you generally enable the first two together and reach for the third when the process itself dies.

Layer 1: Lavalink resume (resumable)Copy Anchor Link

resumable configures the node's Lavalink session to stay alive for timeout seconds if the socket drops. Reconnect within that window and Lavalink hands the same session back — the ready event arrives with resumed: true and the audio never stopped.

const manager = createHoshimi({
  sendPayload,
  nodes: [{ host: 'localhost', port: 2333, password: 'youshallnotpass' }],
  nodeOptions: {
    sessionOptions: {
      resumable: true,
      timeout: 60,
    },
  },
});

This only covers a transient socket drop while your process stays up. If Lavalink itself restarts, or the reconnect misses the window, the session is gone and the next layer takes over.

Layer 2: Library replay (byLibrary)Copy Anchor Link

When the node reconnects on a fresh session (resumed: false) and Hoshimi still holds players in memory, byLibrary replays that state onto the node — reconnecting each player, destroying the empty ones, resending the voice state, syncing the queue and replaying the current track.

const manager = createHoshimi({
  sendPayload,
  nodes: [{ host: 'localhost', port: 2333, password: 'youshallnotpass' }],
  nodeOptions: {
    sessionOptions: {
      resumable: true, // Layer 1 first...
      byLibrary: true, // ...and this is the fallback when the session is fresh.
      async resumeFn(node, players) {
        // Your own reconnect logic, then hand off to the built-in one.
        await resumeByLibrary(node, players);
      },
    },
  },
});

resumeFn runs only while byLibrary is enabled, and defaults to resumeByLibrary when omitted — so leaving it out keeps the built-in behavior.

Layer 3: Rebuild from storageCopy Anchor Link

If the process restarts, the in-memory queue is gone, so neither layer above has anything to resume. Point a queue storage adapter at a durable backend, and after you recreate the player, repopulate its queue from what was persisted.

// Repopulate the in-memory queue from whatever the storage adapter persisted.
await player.queue.utils.sync({ syncCurrent: true });

syncCurrent: true also restores queue.current; see Restore the current track and position to resume playback from where it left off.