Aurabase-logo
aurabasisdocumenten
documenten›Edge Functions›How an invocation works

Hoe een aanroep werkt

Een wandeling door één gesprek, waarin u de limieten, de foutcodes en de timing die u waarneemt, uitlegt.

8 min lezen·Niveau gevorderd·Herzien op 12 okt 2026
Deze Engelse tekst is automatisch gegenereerd op basis van het Franse origineel en is nog niet beoordeeld.
Deze pagina is automatisch vertaald. De Engelse versie is gezaghebbend.
#
Pad

1. Het pad van een oproep

één aanroeptext
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

De gateway en de functiedienst praten via een berichtenbus. Een bericht op die bus heeft een maximale grootte. Daarom wordt een verzoek of antwoord van meer dan ongeveer 256 KiB niet doorgelaten: zie limieten.

#
Looptijd

2. Binnen de looptijd

  • Eén medewerker per oproep. De edge-runtime start voor elke aanroep een nieuwe geïsoleerde V8-werker, met de geheugenlimiet en de time-out van de functie. Niets in het geheugen overleeft van de ene oproep naar de volgende: bewaar de status niet in een variabele. Gebruik uw database of opslag.
  • Code wordt enkele seconden in de cache opgeslagen. De runtime bewaart de code en de limieten van een functie gedurende 5 seconden en verwijdert deze wanneer u deze implementeert. Variabelen worden bij elke oproep gelezen.
  • Uw verzoek is opnieuw opgebouwd. De runtime maakt het verzoek dat u hebt beschreven (method, path, headers, body) en geeft dit door aan uw Deno.serve-handler. Een functie gedraagt ​​zich dus als iedere HTTP-server.
  • De runtime dwingt de time-out af. Wanneer timeout_secs verstrijkt, wordt de werknemer geannuleerd; de beller ziet na ongeveer die vertraging een foutmelding.
  • WASM functies worden binnen de service zelf uitgevoerd, met beperkingen op het gebied van geheugen, tijd en instructies. Een WASM-functie kan logregels rapporteren, die verschijnen in het veld logs van het antwoord; een Deno-functie kan dat niet.
#
Reacties

3. De envelop- en onbewerkte modus

De service heeft twee manieren om het antwoord van uw functie te retourneren, gekozen door de X-Aurabase-Invoke-Mode verzoekheader.

Envelop (standaard)Ruw (raw)
HTTP-statusAltijd 200De eigen status van de functie
Lichaam{ data: { status, headers, body, logs, duration_ms }, meta }De bytes van de functie
InhoudJSON- of UTF-8-tekstAlles, inclusief binair
Gebruikt doorresponseType: 'json', de Studio'text', 'blob', 'arrayBuffer', directe HTTP

De envelop bestaat zodat één JSON-antwoord de status, headers en duur van de oproep kan bevatten. De limiet is dat bytes niet in JSON kunnen reizen: dit is de reden waarom een ​​binair antwoord de onbewerkte modus nodig heeft. De SDK kiest de modus responseType.

In de onbewerkte modus voegt de service x-aurabase-invoke-origin: function toe aan de antwoorden van uw functie. Een fout die afkomstig is van de gateway of de runtime, is niet aanwezig. Dit is hoe de SDK FunctionsHttpError (uw functie beantwoord) scheidt van FunctionsRelayError (het platform is mislukt).

#
Tijd

4. Tijd, meting en storingen

Er zijn drie time-outs genest, zodat geen enkele eindigt vóór de time-out die erin zit:

time-outs, van buiten naar binnentext
gateway 380 s  ⊃  message bus 370 s  ⊃  function timeout_secs (≤ 300 s) + margin

De service wacht op de runtime voor timeout_secs plus een marge. Omdat de runtime de worker op timeout_secs annuleert, ziet u normaal gesproken op dat moment een fout van de functie, en alleen een 504 TIMEOUT als de runtime zelf niet meer reageert. Een 504 betekent dus dat de functie is gestart en mogelijk gevolgen heeft gehad: herhaal een niet-idempotente oproep niet blindelings.

Meting en quota:

  1. Vóór de oproep reserveert de service één aanroep uit het planquotum. Als het quotum is opgebruikt, stopt de oproep hier met 403.
  2. Na het gesprek registreert het de oproep en de duur ervan in milliseconden.
  3. Als de oproep mislukt voordat uw functie antwoordt, wordt de reservering vrijgegeven en wordt er niets geteld.
#
Gevolgen

5. Wat volgt voor uw code

  • Houd elk gesprek kort en staatloos. Voor lang werk zet een taak in de wachtrij.
  • Houd verzoeken en reacties klein; plaats bestanden in Opslag en geef een referentie door.
  • Maak functies idempotent: een nieuwe taak, een nieuwe poging van een client na een netwerkfout of een dubbele cron-levering kan uw code tweemaal uitvoeren.
  • Autoriseer op de identiteitsheaders van het platform, omdat dit de enige waarden zijn die de aanroeper niet kan vervalsen. Zie beveiliging.
  • Meet uw eigen latentie: elke oproep betaalt voor de start van een werknemer. Een minimale functie rapporteerde duration_ms: 74 op een lokale stapel.
Laatst bijgewerkt · 12 okt 2026