Simultaneous Actions Overwriting/Losing Client Changes - Possible Race Condition?

[ugoogalizer]

Summary

My party have used the app for years and love it thank you. We have had for some time had issues where if people in the party make changes at the same time, that those changes sometimes are lost. It appears to be that if buttons are pressed to make an action in gloomhaven secretariat at almost the same time (at least in human perception) then sometimes only one of those actions persist. This can be very frustrating when I've made my change in the app, to only find it disappeared when I next look. This is a frequent occurance for our group. We are based in Australia, and did see the issue more commonly when playing on your publically hosted servers, so we moved to locally hosted using the ghs-server instance (thankyou) which helped reduce the frequency, but the issue is still happening multiple times a game.

I am running server "latest" as at today (I cannot see server version in the logs): and client: v0.131.1

Troubleshooting

I had thought for some time maybe it was just an atomic issue with SQLite, but after moving to the postgres ghs-server variant today, the issue remains the same.

I have tried to replicate the issue, and can share the following observations:

1. We have only run the docker containers, one in plain docker on Synology, another in a k8s cluster. The issue persists across both.
2. Even running the ghs-server locally on the same local network as the clients doesn't prevent the issue
3. Running in Andriod Chrome, Android Firefox, Windows Chrome and Windows Firefox doesn't appear to make a difference, with an exception that I cannot seem to make the issue happen with two different browsers on the same (Windows) device - but I am suspicious that the time it takes me to click in one window and click in the next is too slow (although it's not that slow!)
4. I have set the automatic backups to ghs-server to run every 1 action to try capture the JSON differences (again thanks for helping me fix this in Automatic Backup not working or not clear how to use #42),
   • When the issue occurs, there are two json back up files created, as expected. However, only one of the two actions is recorded as being made in the game section, whereas the undo section records the attempted actions (both the successful and failed actions) as being made. This implies to me that both actions are successfully actioned by something (the client or server), but from a user's perspective only one of them persists and the other user's changes are lost before the backup is actioned.

Interesting Backup Files Demonstrating the Issue

To demonstrate the issue: I have attached two of the json backup files from scenario 1 to this as the simplest example I can do. On device:
A) I attempted to add STUN to Algox Archer 2, and on device
B) I attempted to add IMMOBILISE to Algox Archer 3.
Both actions I tried to commit at exactly the same time (clicking the two mouses at the same time in this instance, but the same happens for us on a touch screen). For whatever reason in this instance, only the IMMOBILISE to Algox Archer 3 persists - I haven't figured out whether that was because I was slightly faster or slower on A or B, or something else yet. Regardless, it's fascinating to see that in neither of the two backups is Algox Archer 2 stunned, both have Algox Archer 3 immobilised, but you can see in the backup triggered by the action from device A, that the undo says the STUN was performed (even though it wasn't applied).

It seems a race condition, with possibly whole game states being committed upon a change, rather than just the atomic change (in this case specific conditions on specific Algox Archers) being made?

Let me know if I can try other things for you, I can spin up a Linux machine or similar also.

Side note

Interestingly this has shown me that backups differ wildly between device (the highly variable file sizes was a big give away), with the obvious difference that I can see that undo history is not backed consistently between devices. I'm suspicious that only undo actions performed on the client itself are what are backed up? Clearing the browser cache, reconnecting, making one change to an existing game then backing up only backs up one undo. This could be intentional though, but at least in this instance it makes it actually easier to see the alleged race condition issue at play.

ghs-autobackup-2025-10-01T11_42_51.334Z (Device A).json

ghs-autobackup-2025-10-01T11_42_51.028Z (Device B).json

[Lurkars]

This is just how the server is currently implemented. It is a simply first-come-first serve, so if two clients have the same game state and simultaneously change something, the both increment the current game revision by 1, then server state is changed by who comes first and the other change get rejected, because the revision is already outdated.

Sadly this is how it works now.

For the undo stack: in general this is just handled locally on a client. Only when you receive a change from server, this is also added to the undo stack. But since this is so much data by now, I won't sync undos to and from server, so if a client is not connected for a while, it will just don't have all the missed states from before, just the newest one.

I am working on new server concept to address all this issues, but don't expect this in near future.

[ugoogalizer]

Thanks mate it's good to understand that this isn't exactly a bug more a reality of the current architecture. Apologies for slow response. We still use it weekly, and just try hard to not dual commit without much issue.

I do ponder though if the server could reject changes that are out of sync/are an unexpected iteration number with the current revision and notify the client to roll back with notification to user that their change didn't persist? Aka, if a client was at state #16, pushes an update to a proposed state #17, but the server is already at #17 (or higher) due another change/s, then the server rejects this client's change and notifies accordingly?

Happy to close regardless if you are.