starred/virtualtabletop

Fork 0

mirror of https://github.com/ArnoldSmith86/virtualtabletop.git synced 2026-03-02 22:57:02 -05:00

run different servers for breaking changes and load incompatible games on older servers #402

New issue

Open

opened 2026-02-20 10:17:12 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 10:17:12 -05:00

Owner

Originally created by @ArnoldSmith86 on GitHub (Nov 11, 2021).

Originally assigned to: @ArnoldSmith86 on GitHub.

We discussed this a long time ago in a few meetings. In general we never want to break existing games because it's really annoying if you start a game on your game night and then notice that something broke since you last played it.

On the other hand there are quite a few engine bugs we want to fix that have the potential to break games.

The solution we came up with was to start an independent server for each engine version that introduces a breaking change. Then, when the user loads an older game, a fileupdater method checks if the game is potentially affected by the change and, if it is, it asks the user if they want to load the game on the current server (potentially broken) or load it on the older version instead.

If it should be loaded in the older version, it would copy the room state (incl. game list) to the older save directory, set a flag in the room state of the current server that tells any connected or connecting client where to go and then it redirects the user's browser to the older URL. Probably something like this:

https://virtualtabletop.io/MyRoom -> https://v5.virtualtabletop.io/MyRoom

The older server has to know that it is old and whenever the player loads another game, it should redirect it back to the current server which in turn needs to transition the state somehow and clear the redirection flag.

That's roughly my current plan and my first goal is to do the same thing with a https://beta.virtualtabletop.io/MyRoom staging server. So you could mark your real game night room as "staging" and it would be redirected to a staging PR without your fellow players having to type in a different URL or update their bookmarks.

I'm opening this issue so we have a place to discuss this thing. I already made a few experiments today and might have a PR soon.

Originally created by @ArnoldSmith86 on GitHub (Nov 11, 2021). Originally assigned to: @ArnoldSmith86 on GitHub. We discussed this a long time ago in a few meetings. In general we never want to break existing games because it's really annoying if you start a game on your game night and then notice that something broke since you last played it. On the other hand there are quite a few engine bugs we want to fix that have the potential to break games. The solution we came up with was to start an independent server for each engine version that introduces a breaking change. Then, when the user loads an older game, a fileupdater method checks if the game is potentially affected by the change and, if it is, it asks the user if they want to load the game on the current server (potentially broken) or load it on the older version instead. If it should be loaded in the older version, it would copy the room state (incl. game list) to the older `save` directory, set a flag in the room state of the current server that tells any connected or connecting client where to go and then it redirects the user's browser to the older URL. Probably something like this: `https://virtualtabletop.io/MyRoom -> https://v5.virtualtabletop.io/MyRoom` The older server has to know that it is old and whenever the player loads another game, it should redirect it back to the current server which in turn needs to transition the state somehow and clear the redirection flag. That's roughly my current plan and my first goal is to do the same thing with a `https://beta.virtualtabletop.io/MyRoom` staging server. So you could mark your real game night room as "staging" and it would be redirected to a staging PR without your fellow players having to type in a different URL or update their bookmarks. I'm opening this issue so we have a place to discuss this thing. I already made a few experiments today and might have a PR soon.

deekerman added the

maintenance

label

2026-02-20 10:17:12 -05:00

deekerman commented

2026-02-20 10:17:12 -05:00

Author

Owner

@RaphaelAlvez commented on GitHub (Nov 11, 2021):

Also should we have it as branches in GitHub? What I'm thinking is that some breaking chances will be restricted to some part of the code.
We could still merge UI updates and bug fixes into it.

I imagine It would also be compatible with PRs

@RaphaelAlvez commented on GitHub (Nov 11, 2021): Also should we have it as branches in GitHub? What I'm thinking is that some breaking chances will be restricted to some part of the code. We could still merge UI updates and bug fixes into it. I imagine It would also be compatible with PRs

deekerman commented

2026-02-20 10:17:13 -05:00

Author

Owner

@robartsd commented on GitHub (Nov 11, 2021):

After we discussed this months ago, I thought I added tags to each commit just prior to a fileupdater commit, but the tags are not there.

If it should be loaded in the older version, it would copy the room state (incl. game list) to the older save directory, set a flag in the room state of the current server that tells any connected or connecting client where to go and then it redirects the user's browser to the older URL.

Could the servers be set up to share a single 'save' directory? Then the room meta data would tell the client which server the room is currently on. Connecting to the room on any server would then be able to redirect to the room on the correct server. Servers would not need to know that they are "old" only that they are not the default server.

@robartsd commented on GitHub (Nov 11, 2021): After we discussed this months ago, I thought I added tags to each commit just prior to a fileupdater commit, but the tags are not there. > If it should be loaded in the older version, it would copy the room state (incl. game list) to the older `save` directory, set a flag in the room state of the current server that tells any connected or connecting client where to go and then it redirects the user's browser to the older URL. Could the servers be set up to share a single 'save' directory? Then the room meta data would tell the client which server the room is currently on. Connecting to the room on any server would then be able to redirect to the room on the correct server. Servers would not need to know that they are "old" only that they are not the default server.

deekerman commented

2026-02-20 10:17:13 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Nov 11, 2021):

We could still merge UI updates and bug fixes into it.

That will probably get painful fast. It could be done of course.

I think it should be the primary goal for everyone to update their games though.

Could the servers be set up to share a single 'save' directory?

Easily, sure. I don't think it's a good idea but maybe it is. I thought I had a reason not to but I can't think of it right now.

Also: it's probably not necessary to migrate any saved room data back to the current server.

@ArnoldSmith86 commented on GitHub (Nov 11, 2021): > We could still merge UI updates and bug fixes into it. That will probably get painful fast. It could be done of course. I think it should be the primary goal for everyone to update their games though. > Could the servers be set up to share a single 'save' directory? Easily, sure. I don't think it's a good idea but maybe it is. I thought I had a reason not to but I can't think of it right now. Also: it's probably not necessary to migrate any saved room data back to the current server.

deekerman commented

2026-02-20 10:17:13 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Nov 11, 2021):

Oh yeah, I would like this stuff to work without requiring the servers to be on the same machine so we could run the auxiliary servers separately.

@ArnoldSmith86 commented on GitHub (Nov 11, 2021): Oh yeah, I would like this stuff to work without requiring the servers to be on the same machine so we could run the auxiliary servers separately.

deekerman commented

2026-02-20 10:17:13 -05:00

Author

Owner

@ArnoldSmith86 commented on GitHub (Dec 1, 2021):

This shouldn't be closed actually. Compatibility servers aren't a thing yet.

@ArnoldSmith86 commented on GitHub (Dec 1, 2021): This shouldn't be closed actually. Compatibility servers aren't a thing yet.

deekerman commented

2026-02-20 10:17:13 -05:00

Author

Owner

@robartsd commented on GitHub (Nov 2, 2022):