Many bugs are about data or concurrency: legacy records from ASP with NULLs or odd encodings, two workers running at the same time.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | # ====================================================================== # Q: How do you reproduce locally a bug that appears only in production? # # Many bugs are about data or concurrency: legacy records from ASP with NULLs or # odd encodings, two workers running at the same time. So: the same PostgreSQL # version, an anonymized dump, a real Celery worker (not eager mode, which hides # race conditions and on_commit). For step-by-step debugging I put in # breakpoint() or attach the IDE through debugpy. # ====================================================================== # docker-compose.debug.yml services: db: image: postgres:16 # same major version as production environment: { POSTGRES_PASSWORD: dev } volumes: ["./dumps:/dumps"] redis: image: redis:7 web: build: . environment: DATABASE_URL: postgres://postgres:dev@db/app CELERY_TASK_ALWAYS_EAGER: "false" ports: ["8000:8000", "5678:5678"] # 5678 for debugpy command: python -m debugpy --listen 0.0.0.0:5678 manage.py runserver 0.0.0.0:8000 worker: build: . command: celery -A app worker -l info --concurrency 4 # anonymized dump from staging # pg_restore -d app --no-owner /dumps/staging_anon.dump |