Saltar al contenido
AX Principios
AX-SYS-40Avanzado

Propaga los plazos y la cancelación a cada llamada delegada

Pass deadlines and cancellation down every delegated call

#mcp#a2a#saas

Cuando un agente le pasa trabajo a otro agente o servicio, transmite cuánto tiempo queda y reenvía la cancelación a cada llamada que inició, para que el trabajo abandonado se detenga en toda la cadena.

Por qué

Las cadenas de delegación son cada vez más profundas: un orquestador le pide algo a un agente de soporte, que llama a un servicio de reembolsos, que llama a un procesador de pagos. Si el orquestador se rinde a los 30 segundos y nadie más abajo se entera, el resto de la cadena sigue corriendo, gastando cuota y reteniendo bloqueos, y puede completar un reembolso que ya nadie espera. gRPC resolvió esto para las llamadas entre servicios y su guía aplica igual aquí. Sin un plazo, un cliente puede esperar prácticamente para siempre; un servidor que llama a otro servidor debería respetar el plazo que fijó el cliente original; y como los relojes no coinciden, gRPC transmite el plazo como un timeout al que ya se le descontó el tiempo transcurrido. Su guía de cancelación añade que, como los servidores suelen ser clientes de otros servidores, una cancelación idealmente debería llegar a todo el trabajo que inició la llamada original. La especificación 2026-07-28 de MCP pide fijar timeouts en todas las peticiones para evitar conexiones colgadas y el agotamiento de recursos, y le dice al servidor que recibe una cancelación que deje de procesar y libere los recursos asociados. También advierte que una cancelación puede llegar cuando el trabajo ya terminó, así que cancelar es una petición, no un deshacer, y quien llama necesita saber qué pasó. AX-SYS-24 le da un identificador a un trabajo largo; este principio cubre la cadena de llamadas que hay detrás.

Haz

Acepta un presupuesto de tiempo en cada llamada delegada, pasa el tiempo restante hacia abajo, cancela las llamadas hijas cuando se cancela la principal e informa qué pasos ya se habían completado.

No hagas

Dejar que las llamadas de más abajo sigan con sus propios timeouts fijos cuando quien llamó ya se fue, ni suponer que una cancelación revirtió el trabajo que ya había terminado.

Artefacto

{ "jsonrpc": "2.0", "method": "notifications/cancelled",
  "params": { "requestId": "req_refund_77", "reason": "Parent task cancelled by orchestrator" } }
{
  "task": "refund_ord123",
  "status": "cancelled",
  "budget_ms": 27500,
  "completed_before_cancel": ["hold_released"],
  "not_started": ["refund_issued", "customer_emailed"]
}

El servicio de reembolsos le dio a la llamada al procesador solo lo que quedaba de su presupuesto de 27,5 segundos, se detuvo al recibir la cancelación e informa que se liberó la retención pero no se emitió ningún reembolso. La notificación es la cancelación de MCP sobre stdio; sobre Streamable HTTP, cerrar el stream de respuesta es la cancelación.

Fuentes

  1. [01]
    gRPC Docs: Deadlines ↗

    By default gRPC does not set a deadline, so a client can end up waiting for a response effectively forever; a server that also acts as a client should honor the deadline set by the original client, and gRPC converts the deadline to a timeout from which the already elapsed time is deducted

  2. [02]
    gRPC Docs: Cancellation ↗

    Servers are often also clients to upstream servers, so cancellation should ideally propagate to all ongoing computation in the system that was initiated due to the original client RPC call

  3. [03]
    MCP Specification 2026-07-28: Cancellation ↗

    Implementations SHOULD establish timeouts for all sent requests to prevent hung connections and resource exhaustion; servers receiving a cancellation SHOULD stop processing the request and free associated resources; because of network latency a cancellation may arrive after processing has completed, and both parties MUST handle that race