Resumen

  • La interrupción de red del 9 de octubre y el fallo del pool de base de datos del 10 fueron incidentes distintos que afectaron a dependencias comunes de ejecución.
  • Algunas ejecuciones con errores internos quedaron en Running: ni onFailure ni las funciones padre que esperaban recibieron una señal de fallo. El cliente debía cancelarlas o reproducirlas.

El valor de una ejecución duradera está en conservar progreso cuando un proceso espera o encuentra un error. Pero la conservación de pasos no responde por sí sola a preguntas operativas: dónde se guarda el estado, qué componentes comparten una cola, qué transición registra una avería interna y quién recibe la señal para actuar. El informe de Inngest sobre el 9, 10 y 11 de octubre sirve para estudiar esas fronteras con detalle.

El 9 de octubre a las 21:05 UTC, uno de los proveedores de Inngest perdió conectividad entre su centro de datos y los otros centros de Inngest, además de acceso saliente a Internet. La explicación inicial del proveedor fue un error al cambiar la configuración de protección contra DDoS. Inngest aún esperaba el informe completo; el punto importa porque la causa era provisional. La conectividad regresó a las 21:49. La noche siguiente ocurrió otra falla, en un subsistema diferente. Los dos PgBouncer que daban acceso a la base principal perdieron todas sus conexiones a las 14:00 UTC del 10 de octubre y volvieron a perderlas a las 15:30.

La planificación de runs y el procesamiento de colas se frenaron para la mayoría de las cuentas. Tras la mitigación, cron siguió sufriendo retrasos intermitentes hasta las 04:17 UTC del 11 de octubre; las rutas de las pasarelas se mejoraron el 12. No fue una falla única que simplemente duró más de un día.

La descripción arquitectónica del primer incidente explica por qué un enlace entre instalaciones tenía un alcance mayor que su ubicación. La ejecución se repartía entre tres centros. Una cuenta podía procesarse en uno y tener el estado necesario en otro; la base de cuentas y configuración, y los poolers que permitían acceder a ella, quedaban con un tercer proveedor. Al romperse la conectividad, los workers de ese centro no podían consultar los datos de la cuenta ni guardar el estado. Los workers en otros lugares también se detenían si el estado del run estaba en el sitio aislado.

Además, los trabajos que fallaban generaban una gran cola en un pipeline de eventos compartido y retrasaban funciones de cuentas que no tenían dependencia directa de ese centro. Las cuentas con pipeline dedicado quedaron fuera de ese efecto. El fallo fue local en origen, pero el pipeline determinó su radio de propagación.

El incidente del 10 de octubre tuvo una mecánica distinta. Consultas de datos con plazos cortos se cancelaban mientras aún esperaban una conexión en PgBouncer. El cliente cerraba su conexión, aunque el pooler podía ejecutar después la consulta abandonada y cerrar la conexión de base de datos en vez de devolverla al pool. Como la apertura de nuevas conexiones era serial, la destrucción podía superar la reposición. La combinación con el pico horario de tareas cron —que aproximadamente triplicaba las consultas— y con nuevas consultas desplegadas antes del fin de semana creó las condiciones para repetir el colapso.

Reiniciar los poolers no era una recuperación fiable; ampliar el tamaño máximo no podía acelerar la creación de conexiones.

Cambiar el punto de entrada de la base resolvió el atasco inmediato, pero añadió una nueva dependencia. Inngest migró los servicios a poolers que el proveedor de la base ejecutaba junto a ella; el procesamiento se recuperó entre las 16:10 y 16:25 UTC. Esa ruta pasaba por gateways NAT que descartaban algunas conexiones sin emitir un error. Las consultas quedaban colgadas hasta 16 minutos, con un impacto visible en las tareas cron. El 11 de octubre a las 04:17 UTC Inngest devolvió la programación cron a los poolers anteriores y el 12 de octubre anunció mejoras de enrutamiento.

Cada alternativa de recuperación debe verificarse en su nuevo camino: una reparación puede cambiar el punto donde se forma la cola.

La brecha más notable no fue sólo técnica, sino de control del estado. Inngest dijo que los fallos internos consumieron los reintentos configurados. Si un paso fallaba definitivamente por un error interno, algunos runs no cambiaban a Failed; permanecían en Running. Como consecuencia, no se avisaba a onFailure ni al padre que aguardaba el resultado mediante step.invoke. La empresa indicó que esos runs no continuaban solos y que los clientes debían cancelarlos o reproducirlos. En un motor duradero, un run que conserva estado pero no informa un resultado terminal deja una responsabilidad activa para quien depende de él.

Las guías explican que al reanudar una función, Inngest puede devolver el resultado guardado de los pasos terminados. El replay que describe el informe es otra operación: vuelve a iniciar el run desde el comienzo, por lo que los pasos ya ejecutados pueden producir sus efectos otra vez. No hay evidencia de que en este incidente se duplicaran pagos, avisos o escrituras. Sí existe un riesgo que los equipos deben evaluar antes de reproducir un lote. Una llamada externa puede haberse completado sin que el resultado llegara al registro del motor.

La guía de idempotencia de Inngest, por eso, recomienda claves estables para operaciones que no deben duplicarse. Guardar checkpoints y garantizar exactamente una vez son propiedades distintas.

Inngest informó de cambios ya aplicados: una consulta en espera ya no se cancela junto con el cliente; los fallos internos definitivos pasan a estado de fallo; si no puede leerse el estado en ese momento, el trabajo permanece en cola y reanuda al recuperarse la lectura. La empresa también mejoró el enrutamiento de los gateways y la rapidez de las actualizaciones de estado. La consolidación planificada en un solo centro de datos sigue en curso. El informe no permite concluir qué redundancias o rutas de recuperación tendrá la topología final.

Fuentes