Commits
Click on a commit to change the comparison rangefix: disable automatic migrations when running with multiple workers
When running the server with multiple workers (--workers > 1), each worker
process would try to run database migrations concurrently during startup.
This caused deadlocks and race conditions, particularly visible in CI where
the test_multi_worker_in_background test would time out waiting for the
server to become healthy.
The fix disables automatic migrations (PREFECT_API_DATABASE_MIGRATE_ON_START=False)
when running with multiple workers. This is the correct behavior because:
1. Multi-worker mode requires PostgreSQL (not SQLite)
2. In production, migrations should be run separately before starting the server
3. Running migrations concurrently from multiple workers is inherently problematic
Fixes flaky test: test_multi_worker_in_background
Co-Authored-By: alex.s@prefect.io <ajstreed1@gmail.com>11 hours ago
by devin-ai-integration[bot] fix: also disable block registration when running with multiple workers
In addition to disabling migrations, also disable block registration
(PREFECT_API_BLOCKS_REGISTER_ON_START=False) when running with multiple
workers. Block registration can also cause race conditions when multiple
workers try to register blocks concurrently during startup.
Co-Authored-By: alex.s@prefect.io <ajstreed1@gmail.com>11 hours ago
by devin-ai-integration[bot] fix: use PostgreSQL advisory locks for multi-worker coordination
Instead of disabling migrations and block registration when running with
multiple workers, use PostgreSQL advisory locks to coordinate these
operations across processes. This ensures only one worker runs migrations
and block registration while others wait, preserving the expected behavior.
For SQLite, the existing threading.Lock() is used since SQLite doesn't
support advisory locks and multi-worker mode is not recommended.
This addresses the reviewer feedback to designate one worker to run
migrations/block registration instead of disabling them entirely.
Co-Authored-By: alex.s@prefect.io <ajstreed1@gmail.com>10 hours ago
by devin-ai-integration[bot] fix: use asyncpg directly for advisory locks instead of psycopg2
The previous implementation used SQLAlchemy's create_engine() with a sync
PostgreSQL URL, which defaults to the psycopg2 driver. However, the project
only has asyncpg installed, not psycopg2.
This fix uses asyncpg directly to acquire and release advisory locks,
avoiding the need for psycopg2 entirely. The implementation handles both
cases: when running in an async context (uses ThreadPoolExecutor) and when
running outside an async context (uses asyncio.run directly).
Co-Authored-By: alex.s@prefect.io <ajstreed1@gmail.com>10 hours ago
by devin-ai-integration[bot]