You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Store lobby data so that it's not lost whenever the bot is restarted.
Reasons for Implementing
When the bot is restarted for an update or maintenance, any lobby in progress is lost.
This causes a few problems:
Users' original nicknames are lost, and can't be restored.
Users are left muted/deafened.
Games in progress are no longer tracked/automated.
Lobby info posts are left behind in text channels.
Ideas & Details
A couple options for storing lobby info:
Use the local file system as a database and use mounted volumes.
Use a remote database (CouchDB?) to store data.
The main problem is how to serialize lobby data in a way that can be recovered. Whichever instance of the bot is handling the shard on startup will need to be able to load the lobby and resume where the previous instance left off.
The capture app shouldn't be a problem, since Socket.IO supports automatic reconnection. It should simply reconnect to the new instance smoothly. Update: While Socket.IO does automatically reconnect, the capture app doesn't resend the connect code. That'll need to be patched.
Alternatives
One other option would be to add a graceful shutdown order which ends all existing lobbies.
The text was updated successfully, but these errors were encountered:
Feature
Store lobby data so that it's not lost whenever the bot is restarted.
Reasons for Implementing
When the bot is restarted for an update or maintenance, any lobby in progress is lost.
This causes a few problems:
Ideas & Details
A couple options for storing lobby info:
The main problem is how to serialize lobby data in a way that can be recovered. Whichever instance of the bot is handling the shard on startup will need to be able to load the lobby and resume where the previous instance left off.
The capture app shouldn't be a problem, since Socket.IO supports automatic reconnection. It should simply reconnect to the new instance smoothly. Update: While Socket.IO does automatically reconnect, the capture app doesn't resend the connect code. That'll need to be patched.
Alternatives
One other option would be to add a graceful shutdown order which ends all existing lobbies.
The text was updated successfully, but these errors were encountered: