Logotipo de Aurabase
aurabasedocumentos
documentos›Edge Functions›How an invocation works

Cómo funciona una invocación

Un recorrido por una llamada para explicar los límites, los códigos de error y los tiempos observados.

8 min leer·Nivel avanzado·Revisado el 12 oct 2026
Este texto en inglés se generó automáticamente a partir del original en francés y aún no ha sido revisado.
Esta página fue traducida automáticamente. La versión en inglés es autorizada.
#
Camino

1. El camino de una llamada

una invocacióntext
your code ── invoke('hello') ──▶ gateway (data plane)
                                   • checks the key and the user's token
                                   • finds the project from the host
                                   • adds x-aura-role, x-aura-user-id, x-aura-project-id
                                   │  message bus (request / reply)
                                   ▼
                           functions service
                                   • access policy: only invoke is public
                                   • reads the function, reserves one invocation of the plan quota
                                   │  HTTP
                                   ▼
                            edge runtime
                                   • loads code, limits and variables
                                   • starts an isolated V8 worker
                                   • rebuilds the request you described
                                   ▼
                             your function ── Response ──▶ back along the same path

La puerta de enlace y el servicio de funciones se comunican a través de un bus de mensajes. Un mensaje en ese bus tiene un límite de tamaño, por lo que una solicitud o respuesta superior a aproximadamente 256 KiB no se procesa: consulte límites.

#
Tiempo de ejecución

2. Dentro del tiempo de ejecución

  • Un trabajador por llamada. El tiempo de ejecución perimetral inicia un nuevo trabajador V8 aislado para cada invocación, con el límite de memoria y el tiempo de espera de la función. Nada en la memoria sobrevive de una llamada a la siguiente: no mantenga el estado en una variable. Utilice su base de datos o almacenamiento.
  • El código se almacena en caché durante unos segundos. El tiempo de ejecución mantiene el código y los límites de una función durante 5 segundos y los elimina cuando se implementa. Las variables se leen en cada llamada.
  • Su solicitud se reconstruyó. El tiempo de ejecución crea la solicitud que usted describió (method, path, headers, body) y se la entrega a su controlador Deno.serve. Por tanto, una función se comporta como cualquier servidor HTTP.
  • El tiempo de ejecución impone el tiempo de espera. Cuando transcurre timeout_secs, cancela al trabajador; la persona que llama ve un error después de ese retraso.
  • WASM funciones se ejecutan dentro del propio servicio, con límites de memoria, tiempo e instrucciones. Una función WASM puede informar líneas de registro, que aparecen en el campo logs de la respuesta; una función Deno no puede.
#
Respuestas

3. La envolvente y el modo raw

El servicio tiene dos formas de devolver la respuesta de su función, elegida por el encabezado de solicitud X-Aurabase-Invoke-Mode.

Sobre (predeterminado)Sin formato (raw)
Estado HTTPSiempre 200El propio estado de la función.
cuerpo{ data: { status, headers, body, logs, duration_ms }, meta }Los bytes de la función.
ContenidoTexto JSON o UTF-8Cualquier cosa, incluido binario
Utilizado porresponseType: 'json', el estudio'text', 'blob', 'arrayBuffer', HTTP directo

El sobre existe para que una respuesta JSON pueda contener el estado, los encabezados y la duración de la llamada. Su límite es que los bytes no pueden viajar en JSON: es por eso que una respuesta binaria necesita modo sin formato. El SDK elige el modo entre responseType.

En modo sin formato, el servicio agrega x-aurabase-invoke-origin: function a las respuestas de su función. Un error que viene del gateway o el runtime no lo lleva. Así es como el SDK separa FunctionsHttpError (su función respondió) de FunctionsRelayError (la plataforma falló).

#
tiempo

4. Tiempo, medición y fallas

Se anidan tres tiempos de espera para que ninguno termine antes que el que está dentro:

tiempos de espera, de afuera hacia adentrotext
gateway 380 s  ⊃  message bus 370 s  ⊃  function timeout_secs (≤ 300 s) + margin

El servicio espera el tiempo de ejecución de timeout_secs más un margen. Debido a que el tiempo de ejecución cancela al trabajador en timeout_secs, normalmente verá un error de la función en ese momento y un 504 TIMEOUT solo si el tiempo de ejecución deja de responder. Por lo tanto, un 504 significa que la función se inició y puede haber tenido efectos: no repita una llamada no idempotente a ciegas.

Medición y cuota:

  1. Antes de la llamada, el servicio reserva una invocación de la cuota del plan. Si se agota la cuota, la llamada se detiene aquí con 403.
  2. Después de la llamada, registra la invocación y su duración en milisegundos.
  3. Si la llamada falla antes de que responda su función, la reserva se libera y no se cuenta nada.
#
Consecuencias

5. Lo que sigue para tu código

  • Mantenga cada llamada breve y sin estado. Para trabajos prolongados, ponga en cola un trabajo.
  • Mantenga las solicitudes y respuestas pequeñas; coloque archivos en Almacenamiento y pase una referencia.
  • Haga que las funciones sean idempotentes: un trabajo reintentado, un reintento de un cliente después de un error de red o una entrega cron duplicada pueden ejecutar su código dos veces.
  • Autorice en los encabezados de identidad de la plataforma, porque son los únicos valores que la persona que llama no puede falsificar. Consulte seguridad.
  • Mide tu propia latencia: cada llamada paga el inicio de un trabajador. Una función mínima informó duration_ms: 74 en una pila local.
Última actualización · 12 oct 2026