- Added dynamic ?v={{ app_version }} cache-busting query strings to all core stylesheet and script references in base.html.
- Created and registered the inject_app_version context processor in app/context_processors.py and app/__init__.py to inject the APP_VERSION environment variable into all templates dynamically.
- Refactored copy-assets.js to detect production context (NODE_ENV=production or DOCKER_BUILD=true) and fail loudly (process.exit(1)) if assets are missing, avoiding silent failures in the build pipeline.
- Set DOCKER_BUILD=true during the Dockerfile asset compilation step to enforce deterministic production build verification.
This fixes a critical issue where Gunicorn workers would fail to start
after upgrading to v2025.11.0, causing containers to show as unhealthy
with only the uv wrapper process running and no actual workers.
Root Cause:
-----------
In v2025.11.0, library scanning and session recovery were added to the
create_app() function, which runs during EVERY app creation including:
1. During 'flask db upgrade' (migrations)
2. During Gunicorn master when_ready() hook
3. During each Gunicorn worker spawn
The migration 20251103_properly_fix_foreign_keys recreates 4 database
tables with CASCADE foreign keys using raw SQL. This holds exclusive
database locks during table recreation.
When library scanning and session recovery try to query these tables
during migration, they hit database locks, creating a race condition
that causes workers to timeout and crash during startup.
Fix:
----
- Skip library scanning during migrations (FLASK_SKIP_SCHEDULER=true)
- Skip activity monitoring/session recovery during migrations
- Make Gunicorn log level configurable (GUNICORN_LOG_LEVEL env var)
- Add worker lifecycle hooks for better crash debugging
- Increase healthcheck start period from 10s to 60s
- Increase Gunicorn worker timeout from 30s to 120s
Testing:
--------
- Verified app starts successfully with FLASK_SKIP_SCHEDULER=true
- Verified library scanning runs normally without the flag
- Confirmed 0.38s startup during migrations vs 1.61s normal startup
Closes#976
Remove --locked flag from uv sync commands in GitHub Actions workflows
and Dockerfiles to allow more flexible dependency resolution during
builds and CI processes.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
The changes that were made to the Dockerfile didn't quite work since environment variables set at runtime won't change anything that uses them in the Dockerfile. So the user/group creation needs to happen in the docker-entrypoint.sh script so that if the user/group is set as an environment variable it will create a the user/group properly and take ownership of the required folders.
Wizarr used to work by just setting PUID and PGID environment variables but 2025.6.1 broke this behavior and setting user:group at runtime doesn't seem to work correctly either. This brings it back to how it worked before 2025.6.1
