search

kestasjk / webDiplomacy

Play Diplomacy online
http://webdiplomacy.net/
GNU Affero General Public License v3.0
179 stars 113 forks source link

Release beta v2 0.3 #802

Closed adamlerer closed 2 years ago

adamlerer commented 2 years ago

Release v0.3 of the new beta UI.

IMPORTANT notes:

  1. Unlike previous beta versions, this one makes db modifications, meaning we will have to upgrade to 1.70. master is still on 1.68 though, so what do we do? We can either upgrade to 1.70 in prod, or switch the 1.69 and 1.70 changes and switch to 1.69 ...
  2. Should this be merged into master or staging?

Feature list:

adamlerer commented 2 years ago

@kestasjk I tried resolving the merge conflicts here, but at least on my private instance, I found that the current master branch isn't working properly (gamemaster doesn't start bot games, cancel doesn't work, etc.) so I was wondering if your changes from a few hours ago might have broken something.

Are changes on master auto-synced to webdiplomacy.net ? Because things are working fine there.

kestasjk commented 2 years ago

Hi Adam, Hmm that's odd..

I changed how votes are handled since it wasn't working reliably; PHP logic detected when a vote passed, and the logic was at a point where I didn't understand the intent. Also because it was in PHP you couldn't search for votes that need processing, you had to detect it when the vote is submitted or game is viewed by a player and then set a flag in memcache for the gamemaster to handle. I replaced it with a query to search for votes to process that ignores votes from bots entirely. This is a change to the previous logic which did factor in votes from bots, but I couldn't make sense of what it was trying to do where it would sort of allow votes depending on whether the bot had gained or lots supply centers in the last 2-4 turns, so I figured (since it wasn't working for many anyway) I would simplify it right down and see if any issues arose.

Possibly unrelated but FYI: We were also still getting deadlocks / lock timeouts appear in the error logs that I wanted to resolve. When looking into the API I realized it was locking games for update, the most strict and intrusive lock type, to do read-only operations including just checking whether a user was in a game. With hindsight I'm impressed (with the hardware) that the site never became totally inoperable. Part of the reason is knowing the new board does do a lot of background server requests, and I want to add an instant-play feature so anyone can go to a URL, no account needed, start a bot game and leave when they like, which might increase server load.

Yep webdiplomacy.net syncs with the master branch automatically, and it is in sync at the moment. Is it 1 human games that aren't processing or multi-human games, and are full human games processing? I didn't change how the gamemaster does game processing and it is working so I'm not sure what's going on there. I can see you've got some changes talking about database changes / vote processing etc so maybe there's a merge conflict of some sort. I want to try and finish up a couple of features today but I might be able to look at this merge. I do also want to get staging up to pace with the master branch so you can merge with staging again.

I'll try and bring the database/code version up to 1.71 today, and do a test of a clean install in docker, so you can merge in the database changes neatly into 1.72 via a install/1.71-1.72/update.sql script.

adamlerer commented 2 years ago

Thanks @kestasjk . Yeah, the vote logic was hard for me to understand as well, I sort of treated it as a black box. Once you update the code I'll probably start from scratch on how to initiate vote processing from the setVote API call (let me know if you have a suggestion).

Re locking: I didn't write this code, not surprised that this happened because the getAssociatedGame function was originally written for a limited purpose and got cargo-culted around for various purposes. Lucky it didn't cause any problems.

What's not working on my end is the processing (starting) of all-bot games. I haven't experimented with anything else.

I'll take another pass once you make your changes.

kestasjk commented 2 years ago

Righto didn't get the anonymous game suspicion stuff done, but I've wrapped everything up and started a new release 1.70, and I've tested out a fresh install from the docker composer to check that it's all working. Next dev cycle probably won't be for a few weeks so that should let you make your changes without any moving parts.

adamlerer commented 2 years ago

Okay, I've merged in the latest master, things seem to be working correctly now.

@kestasjk there are still a couple things that aren't working quite properly for me right now:

  1. The UI behaves weirdly when you cancel a game, in either the old or new UI. To repro: create a bot game, then press cancel, in either UI. (The cancellation works, but the UI misbehaves because the game has disappeared).
  2. When I run docker-compose up, memcached doesn't work. The reason is that the memcached server is exposed as memcached:11211, while the PHP code looks for 127.0.0.1:11211. Solutions I've found are either to change the PHP code to $MC->addServer("memcached", 11211); or docker exec into the PHP machine and set up memcached there.

@TimothyJones I addressed some of your comments, but some of them would be better suited to a follow-up PR. It would certainly be great if you had time to improve the beta code systematically, there's definitely a lot of things that could be cleaned up and made more idiomatic. But I don't think fixing them locally in just a single place is worth it, and I don't want to do too much more in this PR since it's already quite large.