El contenedor Redis (zqmfom0vw6nj3ae66mkwxek1) vive en la red 'coolify'.
La app estaba solo en la red nj05x5... → DNS SERVFAIL → health.php tardaba
10-12s intentando conectar → healthcheck timeout → unhealthy → 'no available server'.
Solución: declarar red coolify como external y conectar el servicio app.
Fix inmediato aplicado manualmente con: docker network connect coolify <container>
06_master_sync.sql:
- Comentario tenía ';' (La columna role_id ya existe; la FK) →
el parser de migrate.php divide por ; y el texto 'la FK' quedaba
como sentencia SQL → error SQLSTATE[42000]
docker-compose.yml:
- Eliminar whatsapp-network (red bridge propia)
- Con 1 solo servicio no se necesita red interna
- Coolify añade automáticamente su red nj05x5... (donde está Traefik)
- La red bridge extra podría interferir con el routing de Traefik
health.php:
- DB fallo → 'warning' (no 'unhealthy', no cierra tráfico Traefik)
- Redis ya era warning desde commit anterior
docker-compose.yml:
- timeout: 5s → 10s (DB externa puede tardar más)
- start_period: 40s → 60s (tiempo suficiente para that migrations corran)
- fallback: si health.php falla, intenta / raíz antes de marcar unhealthy
- Eliminar container_name (Coolify asigna su propio nombre, conflicto evitado)
- Eliminar ./:/var/www/html (bind mount sobreescribía código del contenedor en prod)
- Eliminar ./logs y ./uploads bind mounts (reemplazados por named volumes)
- Eliminar php-socket volume (ya no se usa)
- Usar named volumes app-logs/app-uploads (persistencia correcta en Coolify)
1. ADD CONSTRAINT IF NOT EXISTS no es estándar en MariaDB < 10.5 —
eliminado el bloque FK de admin_users.role_id (la integridad la
gestiona la aplicación).
2. AFTER `pdf_path` fallaba porque la columna no existe en lab_form_envios —
eliminado el AFTER, la columna se agrega al final de la tabla.
Esto evita que la migración falle en cada deploy.
Redis es externo (Coolify managed) — esperar con redis-cli causaba
30 segundos de delay en cada arranque porque:
1. redis-cli no pasaba -a $REDIS_PASSWORD (auth fallaba)
2. Redis no es local, no tiene sentido hacer ping desde dentro del contenedor
La app conecta a Redis cuando necesita (RedisQueue, ConversationState, etc.)
Redis es infraestructura opcional — si falla la conexión, retorna 'warning'
en lugar de 'unhealthy', evitando que Traefik muestre 'no available server'.
Solo DB down debe marcar el app como unhealthy (es crítico).
isInstallationCompleted() en config.php busca '.installation_completed' (con punto)
pero el Dockerfile solo creaba 'installation_completed' (sin punto).
Ahora se crean ambas variantes para cubrir todos los checks del código.
- Redis ahora es un Database Resource externo en Coolify
Configurar: REDIS_HOST, REDIS_PORT, REDIS_PASSWORD en env vars
- Worker corre dentro del contenedor app via Supervisor (no servicio aparte)
- Eliminados: servicio redis, worker, redis-commander, volumenes db-data/redis-data
- Solo queda: servicio app + volumen php-socket
- entrypoint.sh: Redis wait tenía loop infinito sin timeout → el contenedor
se quedaba colgado para siempre si Redis tardaba, causando 504 Gateway Timeout
Ahora tiene MAX_RETRIES=15 (30s) y continúa aunque Redis no esté disponible
- entrypoint.sh: removido set -e para que errores no-críticos (permisos,
SSL, etc.) no maten el arranque del contenedor
- docker-compose.yml: removido depends_on redis con condition:service_healthy
Docker bloqueaba el inicio de app hasta que Redis estuviera healthy,
lo que podía exceder el timeout de Traefik
Sin este archivo, config.php ejecuta con display_errors=1 (modo dev).
Los PHP warnings se inyectaban dentro del bloque <script> de las páginas,
rompiendo el JavaScript y causando que el contenido no se renderizara.
El archivo se crea en el RUN del Dockerfile así sobrevive cada deploy.
20260304_roles_seed_data.sql — inicializa datos en roles/role_modules
y vincula admin_users.role_id. Todos los statements son idempotentes
(UPDATE + INSERT IGNORE), por lo que se pueden re-ejecutar sin problemas.
Esto asegura que en cualquier deploy los módulos de rol y los colores
estén correctos, aunque la migración DDL ya haya sido registrada.
Si una migración está en la tabla migrations pero la tabla que crea ya
no existe en la BD (ej. Coolify recreó la DB), el sistema la re-ejecuta
automáticamente. Esto evita el error anterior donde 10 lab migrations
estaban registradas como ejecutadas pero las tablas no existían.
El archivo docker-compose.yml es el que usa Coolify por defecto.
Con 'ports: 8080:80' Traefik no sabía a qué puerto rutear en cada
redeploy. Con 'expose: 80' Traefik detecta el puerto 80 del contenedor
directamente (igual que docker-compose.prod.yml).
Para desarrollo local usar: docker-compose -f docker-compose.dev.yml up
- Eliminar comentarios de bloque /* */ antes de parsear
- Limpiar líneas vacías y comentarios -- sentencia por sentencia
- Agregar 'Duplicate key name' y 'Multiple primary key defined' a errores ignorables
- Solo registrar en tabla migrations si no hubo errores reales
- Si una sentencia falla, continuar con las demás pero marcar had_error=true
El contenedor falla al subir a Facebook archivos >~200KB por renegociacion
TLS de OpenSSL 3.x (errno 55). Solucion sin rebuild:
- Archivos <=200KB: uploadMedia() como antes (funciona OK)
- Archivos >200KB: enviar URL publica - WhatsApp descarga desde el servidor
directamente, sin pasar por el contenedor ni por OpenSSL
Aplica a imagenes, documentos, videos y audios.
OpenSSL 3.x en contenedor hace renegociacion TLS con Facebook >~300KB
causando errno 55. Forzar imagen a quedar bajo 250KB:
- Escalar a max 1920px si es más grande
- Intentar JPEG q=0.85, 0.70, 0.55, 0.40, 0.25 hasta pasar el umbral
- JPEG/WebP ya bajo 250KB se pasan sin modificar
Imagen PNG del portapapeles puede ser 1-5MB sin comprimir.
Facebook resetea TCP (errno 55) al recibir payloads grandes desde el
contenedor con OpenSSL 3.x. Solución: convertir PNG→JPEG 0.85 vía Canvas
en el navegador antes de subir → reduce tamaño ~10x → upload exitoso.
JPEG/WebP ya comprimidos se pasan sin modificar.
Lizandro Guarnizo