El valor de Durable Task no reside en sustituir cada trabajador en segundo plano, cola de mensajes o base de datos, sino en organizar operaciones que se prolongan en el tiempo, se detienen a la espera de un evento externo o pueden interrumpirse después de ejecutar parte de sus pasos. El blog de .NET presenta cinco ejemplos prácticos con el paquete Durable Task .NET SDK, versión 1.26.0, junto con Durable Task Scheduler, y recalca que la herramienta conserva el historial de coordinación, pero no recupera una pila de ejecución de CLR suspendida.
La idea central es separar lo que coordina el motor del flujo de trabajo de lo que sigue siendo responsabilidad de la aplicación. Durable Task puede guardar puntos de progreso, esperar sin mantener ocupado un hilo de ejecución y volver a ejecutar el código del orquestador basándose en los resultados registrados. Sin embargo, no decide los permisos de los usuarios, no garantiza que los efectos externos se ejecuten exactamente una vez ni determina por sí solo qué recursos pueden eliminarse de forma segura o si un pago ha llegado realmente.
La aprobación humana no significa detener al trabajador
En el procesamiento de facturas, cada factura puede ejecutarse dentro de una suborquestación independiente. Las facturas que no requieren revisión continúan su recorrido, mientras que la factura que requiere aprobación humana espera un evento externo y un tiempo de espera durable. Si el trabajador se detiene, otro trabajador puede volver a ejecutar el orquestador y regresar al punto de espera en lugar de reconstruir el estado manualmente.
No obstante, el evento de aprobación es solo una señal. Un punto de conexión documentado debe registrar atómicamente la decisión final en el almacén de la aplicación antes de enviar la señal, y el paso contable debe verificar una identidad de publicación estable y una huella de solicitud inmutable. Si el asiento contable se acepta y después se pierde la confirmación de la actividad, el historial de Durable Task no basta para impedir la duplicación; se necesita un protocolo de conciliación con el sistema contable.
Configuración de un entorno de Azure: ¿dónde termina el papel de ARM?
El artículo explica que ARM y Bicep pueden bastar para implementar recursos determinados, ya que proporcionan ordenación de dependencias, ejecución paralela y reaplicación del estado deseado con identidades estables. Por ello, añadir Durable Task no merece la pena para reconstruir un grafo de implementación que ARM ya proporciona.
La utilidad aparece cuando el flujo va más allá de implementar recursos e incluye aceptar una solicitud del inquilino, informarle del progreso, esperar a que esté listo y, después, activar el inquilino. El ejemplo propone guardar la solicitud de configuración y sus identificadores en la base de datos de la aplicación junto con un outbox, y utilizar una orquestación que conecte las etapas de red, base de datos, almacenamiento, aplicación, DNS y comprobación de disponibilidad. Sin embargo, las operaciones de Azure siguen necesitando registros de operaciones, identidades estables y conciliación cuando se pierden respuestas.
El artículo advierte que no se debe considerar la compensación como un botón de deshacer. Azure podría seguir creando una base de datos después de que falle el almacenamiento. Por ello, hay que impedir que el intento antiguo inicie nuevas operaciones, comprobar las operaciones enviadas anteriormente y eliminar únicamente los recursos que sean propiedad exclusiva del intento después de confirmar que no existen operaciones retrasadas que puedan volver a crearlos. Si no se puede demostrar el estado o la propiedad, el resultado seguro es NeedsIntervention, no una eliminación especulativa.
El vencimiento del tiempo de espera del pago no es un rechazo
En el ciclo de una suscripción, la respuesta de un proveedor de pagos puede desaparecer después de que la operación haya sido aceptada. Reintentar de inmediato podría aplicar un cargo doble, mientras que considerarla rechazada podría enviar una alerta engañosa. El ejemplo propone vincular cada ciclo de pago a un identificador de ciclo y a una clave de pago estable, y después utilizar temporizadores durables, llamadas de retorno, comprobaciones periódicas y un periodo de gracia definido.
El libro mayor de pagos sigue siendo la fuente authoritative para los estados Unknown, Pending, Declined, Paid y NotCharged. El ciclo no pasa al siguiente hasta que se confirma el recibo y se cierra el ciclo actual. Si el tiempo de espera termina mientras el estado sigue sin resolverse, el resultado es NeedsReconciliation, en lugar de suponer que el pago se realizó o falló.
Los eventos tardíos necesitan protección en el destino
En la actualización de un índice de búsqueda de artículos de noticias, la versión 12 puede llegar después de la versión 13, o las operaciones de indexación pueden finalizar en orden inverso. La entidad durable puede conservar la versión más alta observada y secuenciar las actualizaciones de sus contadores, pero no bloquea el índice externo ni impide que dos solicitudes escriban en paralelo.
Por ello, el propio destino debe imponer una barrera de versión atómica que rechace la escritura de una versión anterior después de que se haya fijado una versión más reciente. El sistema también necesita un inbox fiable, un distribuidor de seguimiento y una conciliación periódica con el origen. Incluso el patrón de un orquestador con un único identificador no ofrece una garantía de ejecución exactamente una vez para los efectos externos.
¿Qué significa esto para los agentes de inteligencia artificial?
En un flujo de trabajo de asistente de incidentes, la operación requiere conservar la propuesta específica del modelo, esperar la aprobación del ingeniero y ejecutar después la herramienta aprobada tras una posible interrupción. El valor reside en recuperar el mismo recorrido de aprobación y la misma decisión, no en volver a generar una propuesta nueva después de cada reinicio. La identidad de la propuesta, la validez de la herramienta y la prevención de la ejecución de una solicitud antigua o duplicada siguen siendo responsabilidades de la aplicación.
La conclusión práctica de los cinco ejemplos es que Durable Task resulta adecuado cuando conservar «qué ocurrirá después» se convierte en un sistema por derecho propio. Sin embargo, si la aplicación ya dispone de colas, temporizadores y registros de conciliación claros, o si el sistema externo proporciona una coordinación fiable como ARM, el marco puede añadir más complejidad que valor. Además, todos los ejemplos dependen de límites externos explícitos: un registro autoritativo, una clave de idempotencia, una barrera de versión, un outbox o un protocolo de conciliación.