❌ Athena deja de funcionar: el sidecar DuckDB se queda sin memoria

Verificado el 2026-08-08 contra Floci 1.6.0. El fallo más costoso de diagnosticar de todo el curso.

🔍 El síntoma

Todas las consultas —hasta un SELECT COUNT(*) sobre un CSV de 349 bytes— fallan:

floci-duck execute returned HTTP 500: {"status":"error","message":"Out of Memory Error:
could not allocate block of size 76.5 MiB (31.5 MiB/102.3 MiB used)"}

Lo desconcertante: el host tenía 5.5 GB libres. El límite no es del servidor, es del contenedor.

docker inspect floci-duck --format '{{.HostConfig.Memory}}'
# 134217728    → 128 MiB fijos, impuestos por Floci

DuckDB se reserva ~102 MiB de esos 128 y falla al pedir bloques mayores. No hay ninguna variable de entorno documentada para cambiarlo (FLOCI_SERVICES_DUCK_* solo permite fijar la imagen y la URL).

🔁 Lo que NO funciona (probado en este orden)

Intento	Resultado
docker restart floci-duck	El mismo error de memoria
docker rm -f floci-duck	Empeora: Failed to call floci-duck execute: No route to host
Vaciar el bucket de resultados	Sin efecto (solo había 1 archivo)

El segundo es el más traicionero: Floci guarda la dirección del sidecar en memoria, así que al eliminarlo sigue hablando con la IP anterior.

✅ Lo único que funciona

floci restart

Precio: se borra todo el estado en memoria — buckets, tablas, catálogo de Glue. Hay que volver a montar el lago entero.

💡 Por eso conviene tener el montaje del data lake en un script, no en comandos sueltos: cuando esto pase, se rehace en un segundo.

📝 Qué aprender de aquí

Cuando un servicio falla, el reflejo es reiniciar el componente que da el error. Aquí ese reflejo no solo no ayuda: eliminarlo empeora el diagnóstico, cambiando un error claro (memoria) por uno engañoso (red). Merece la pena parar y entender la arquitectura antes de reiniciar cosas.