Temporal 1.32 en bodegas: colas, reintentos y evidencia
Caso anonimizado para ordenar despachos con workflows durables, workers, colas, visibilidad operativa y restauración con PostgreSQL en una bodega exportadora.
El despacho queda colgado cuando la orden fiscal, el remito y el turno de transporte avanzan a ritmos distintos. En una bodega exportadora de Luján de Cuyo, ese síntoma se repetía cada cierre de semana: un paso fallaba, otro se reintentaba a mano y nadie sabía qué quedó pendiente. Temporal permite modelar workflows durables con workers y colas. Este caso muestra qué se configura primero y cómo se prueba la salida. ## Dónde aparece el trámite partido Temporal publicó v1.32.1 el 8 de octubre de 2026, con correcciones sobre tareas, colas y versión de CLI. La versión llegó días antes de esta corrida y sirve como recordatorio operativo: cuando el proceso depende de varios sistemas, el orquestador también necesita ventana de cambio y reversa. El número que ordena la escena viene de la documentación de workers. Temporal indica que un worker individual puede manejar millones de ejecuciones abiertas si tolera la tasa de actualización y cierta latencia. La cifra no invita a sobredimensionar; permite entender por qué el cuello aparece en eventos, permisos y consultas, antes que en la cantidad nominal de trámites. El antagonista es la tarea pegada al chat: alguien escribe "reenviar remito" y ese mensaje pasa a ser el estado del despacho. El objeto que delata el problema es una carpeta azul con separadores gastados: fiscal, depósito, transporte, cliente. Cuando cada separador vive en un sistema distinto, el atraso se vuelve difícil de reconstruir.
Cómo funciona por dentro
El flujo tiene seis pasos. Primero, el sistema comercial crea una orden de despacho con cliente, lote, fecha y prioridad. Segundo, una aplicación inicia un workflow de Temporal con ese id. Tercero, workers externos toman actividades: validar documentación, pedir turno, generar remito, avisar a transporte y cerrar evidencia. Cuarto, las task queues separan trabajos fiscales, logísticos y de comunicación. Quinto, PostgreSQL guarda datos propios de la aplicación y Temporal guarda historial de ejecución en su persistencia. Sexto, visibilidad y backup permiten buscar workflows, restaurar base y repetir un caso de ensayo. La documentación de workflows define el workflow como la unidad que conserva estado y avanza por eventos. La documentación de workers explica que los workers son procesos externos que toman tareas, ejecutan código y devuelven resultados al servicio. Esa separación ayuda a una bodega: el servicio orquesta, los workers llaman a AFIP, ERP, correo o depósito. La documentación de task queues ubica dónde esperan las tareas. Una cola fiscal puede tener workers con credenciales y horario propio; una cola de transporte puede enviar avisos y reintentar. La visibilidad permite consultar ejecuciones por estado, tipo y atributos de búsqueda, útil para saber qué despacho quedó abierto.
Qué se instala o configura primero
El primer entregable verificable es un flujo de veinte despachos de prueba: cinco completos, cinco con falta de documentación, cinco con rechazo de transporte y cinco cancelados. Cada ejecución necesita id de orden, estado, responsable, actividad pendiente, error legible y evidencia final. La pila mínima usa Temporal 1.32.1, PostgreSQL 17 para la aplicación, workers en Node.js, Go o Python, una cola por tipo de tarea, panel de visibilidad, logs y backup. El costo mensual de un piloto chico ronda USD 60 a USD 140 para servidor, base, almacenamiento y copia externa. Con dólar oficial vendedor a ARS 1535, queda entre ARS 92.100 y ARS 214.900. El rango excluye integraciones con ERP, fiscal y transporte. UMSA puede entrar cuando la bodega ya nombró los estados del proceso y los responsables. La implementación útil empieza por una sola ruta: orden creada, documentación validada, turno confirmado, remito generado, aviso enviado y cierre con evidencia. El valor para gerencia no está en ver una consola técnica. Está en abrir una orden y leer qué paso espera, qué worker lo tomó, qué error devolvió y cuándo se reintenta.
Dónde se rompe y cómo probarlo
El primer riesgo aparece en actividades que no son idempotentes. La señal es un remito duplicado después de un reintento. La prueba corta la conexión durante una actividad, deja que Temporal reintente y verifica que el sistema externo reciba una sola operación válida. El segundo riesgo vive en colas mezcladas. La señal es que un worker de avisos toma una tarea fiscal. La prueba crea tres task queues, apaga una y confirma que las otras sigan procesando sin robar tareas. El tercer riesgo aparece en visibilidad pobre. La señal es una ejecución fallida sin cliente, lote ni responsable para buscar. La prueba carga atributos de búsqueda, filtra diez órdenes y exporta el listado de pendientes. El cuarto riesgo es restaurar solo la aplicación. La señal es que PostgreSQL vuelve, pero los workflows quedan huérfanos. La prueba restaura base, configuración y servicio Temporal en ensayo; después abre una ejecución, consulta su historial y completa una actividad pendiente. El cierre tiene una acción concreta: elegir un flujo corto, hacerlo fallar a propósito y guardar la evidencia antes de sumarle más rutas.
