- dev/migrations/001-innodb.sql: convert pqs_queue + pqs_mission to InnoDB. - includes/queue.php: pqs_enqueue_player() seats a player in the next open mission (creating one if needed), serialized with GET_LOCK and wrapped in a transaction; capacity judged by real COUNT(*), numplayers rewritten from it so the counter self-heals and can't drift. - callsign.php: normal registration path now calls pqs_enqueue_player instead of the non-atomic read-check-insert. Verified on the local stack: 140 concurrent registrations -> 24 missions, zero overfill, zero counter drift. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dev/ — local test environment
Tooling to run PQS locally for testing, not part of the deployed app.
The venue server is Debian + PHP + MySQL. The closest local mirror on this machine is WSL2 Ubuntu, so we test there.
First-time setup
From a WSL Ubuntu shell, in the repo root:
bash dev/setup-local.sh
This installs php-cli, php-mysql, and mariadb-server, creates the pqs
database + pqs/pqs user, and loads docs/pqs.sql. You'll be asked for your
sudo password. It's idempotent — safe to re-run.
Running the app
# serve the PARENT of the repo so the app's hardcoded /pqs/ URLs resolve
php -S 0.0.0.0:8080 -t /mnt/c/VWE
Then browse:
- Kiosk: http://localhost:8080/PQS/callsign.php
- Reg console: http://localhost:8080/PQS/registration.php
- Ops console: http://localhost:8080/PQS/console.php
- Queue wall: http://localhost:8080/PQS/combinedqueue.php
Notes / caveats
- PHP version differs from the venue. Ubuntu 24.04 ships PHP 8.3; the venue
box was PHP 5.4. We keep application code compatible with 5.5+ so it runs in
both, but PHP 8 is stricter — the legacy
mysql_*calls in the original code will fatal here until they're replaced (which is part of the improvement plan). - MariaDB stands in for MySQL 5.5. Fine for our purposes: InnoDB, transactions, and the SQL this app uses are all equivalent.
- After a WSL restart the DB is stopped; run
sudo service mariadb start. - This is a throwaway DB with no real player data.