Critical bug fix for issue where Groundball A with runner on first would fail to execute a double play after game recovery from database. Root cause: current_on_base_code field was not recalculated during state recovery, defaulting to 0 (empty bases) even when runners were on base. This caused runner advancement logic to select Result 1 (batter out, runners hold) instead of Result 2 (double play). Changes: - Added calculate_on_base_code() helper method to GameState model - Updated _prepare_next_play() to use helper (eliminates duplication) - Fixed state recovery to calculate current_on_base_code from runners - Fixed X-Check G1 mapping (was GROUNDBALL_B, should be GROUNDBALL_A) - Added 5 regression tests to prevent recurrence Testing: - All 359 unit tests passing - New regression tests verify fix and demonstrate bug scenario - Tested in network dev environment - double plays now work correctly Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| .claude | ||
| .git-hooks | ||
| alembic | ||
| app | ||
| scripts | ||
| terminal_client | ||
| tests | ||
| .dockerignore | ||
| .env.dev | ||
| .env.example | ||
| .env.network | ||
| .env.prod | ||
| .gitignore | ||
| .python-version | ||
| alembic.ini | ||
| CLAUDE.md | ||
| clean_test_data.py | ||
| docker-compose.yml | ||
| Dockerfile | ||
| mypy.ini | ||
| pyproject.toml | ||
| pyrightconfig.json | ||
| pytest.ini | ||
| README.md | ||
| requirements-dev.txt | ||
| requirements.txt | ||
| TEST_COVERAGE_SUMMARY.md | ||
| test_db_playground.py | ||
| test_pd_api_live.py | ||
| test_pd_api_mock.py | ||
| test_redis_cache.py | ||
| uv.lock | ||
Paper Dynasty Backend
FastAPI-based real-time baseball game engine with WebSocket support.
Quick Start
# Install UV
curl -LsSf https://astral.sh/uv/install.sh | sh
# Install dependencies
uv sync
# Apply database migrations
uv run alembic upgrade head
# Run server
uv run python -m app.main
Database Migrations
This project uses Alembic for database schema migrations.
Initial Setup (New Database)
# Apply all migrations to create schema
uv run alembic upgrade head
Creating New Migrations
# Auto-generate from model changes
uv run alembic revision --autogenerate -m "Description of changes"
# IMPORTANT: Always review the generated migration before applying!
# Then apply:
uv run alembic upgrade head
Viewing Migration Status
# Show migration history
uv run alembic history
# Show current revision
uv run alembic current
Rolling Back
# Rollback one migration
uv run alembic downgrade -1
# Rollback to specific revision
uv run alembic downgrade 001
# Rollback all (dangerous!)
uv run alembic downgrade base
Migration Best Practices
- Always review auto-generated migrations before applying - autogenerate is helpful but not perfect
- Test migrations on dev/staging before production
- Keep migrations small and focused - easier to rollback
- Never edit migrations that have been applied to shared databases
- Include both upgrade and downgrade for reversibility
Existing Migrations
| Revision | Description |
|---|---|
| 001 | Initial schema (games, plays, lineups, rolls, etc.) |
| 004 | Materialized views for statistics |
Documentation
See CLAUDE.md for full documentation.