Is there an existing issue for this?
Current behavior
When spinning up the local development environment using Docker Compose on a clean slate (no logs directory exists), multiple backend services attempt to create the logs directory at the same time. This triggers a race condition, causing the containers to crash with a FileExistsError and leaving the UI stuck on the loading page.
I expect all backend Docker containers to boot up concurrently and successfully wait for the database migrations to finish, resolving the directory creation safely.
Steps to reproduce
- Clear the local logs directory or use a clean docker-compose build volume.
- Run
$env:PATH += ";C:\Program Files\Docker\Docker\resources\bin"; docker compose -f docker-compose-local.yml up -d --build to start the local stack.
- Check container logs (
docker logs plane-migrator-1).
- See the following Python error traceback:
migrator-1 | Traceback (most recent call last):
migrator-1 | File "/code/manage.py", line 19, in <module>
migrator-1 | execute_from_command_line(sys.argv)
migrator-1 | ...
migrator-1 | File "/code/plane/settings/local.py", line 38, in <module>
migrator-1 | os.makedirs(LOG_DIR)
migrator-1 | File "<frozen os>", line 225, in makedirs
migrator-1 | FileExistsError: [Errno 17] File exists: '/code/plane/logs'
Why this happens (and why it might have been missed previously):
Directory already exists: Once the logs/ folder is successfully created once on the host filesystem, the crash code path is bypassed forever.
Confronted on clean setup: It only shows up during a completely clean, first-time docker-compose boot (or when build volumes/folders are purged).
Confronted on multi-core systems / Windows WSL2: On fast multi-core CPUs, Docker Compose starts the containers simultaneously. Since Windows filesystem operations through WSL2 mounts (./apps/api:/code) have higher latency than native Linux, the time window between the check and the actual directory creation is wider, triggering the race condition.
Proposed Fix:
Use exist_ok=True to make the directory creation thread-safe:
os.makedirs(LOG_DIR, exist_ok=True)
Environment
Production
Browser
Google Chrome
Variant
Local
Version
v1.3.1-dev
Is there an existing issue for this?
Current behavior
When spinning up the local development environment using Docker Compose on a clean slate (no logs directory exists), multiple backend services attempt to create the logs directory at the same time. This triggers a race condition, causing the containers to crash with a
FileExistsErrorand leaving the UI stuck on the loading page.I expect all backend Docker containers to boot up concurrently and successfully wait for the database migrations to finish, resolving the directory creation safely.
Steps to reproduce
$env:PATH += ";C:\Program Files\Docker\Docker\resources\bin"; docker compose -f docker-compose-local.yml up -d --buildto start the local stack.docker logs plane-migrator-1).Why this happens (and why it might have been missed previously):
Directory already exists: Once the logs/ folder is successfully created once on the host filesystem, the crash code path is bypassed forever.
Confronted on clean setup: It only shows up during a completely clean, first-time docker-compose boot (or when build volumes/folders are purged).
Confronted on multi-core systems / Windows WSL2: On fast multi-core CPUs, Docker Compose starts the containers simultaneously. Since Windows filesystem operations through WSL2 mounts (./apps/api:/code) have higher latency than native Linux, the time window between the check and the actual directory creation is wider, triggering the race condition.
Proposed Fix:
Use exist_ok=True to make the directory creation thread-safe:
Environment
Production
Browser
Google Chrome
Variant
Local
Version
v1.3.1-dev