Tester et superviser des functions

Les deux outils se trouvent dans l'éditeur de la function : testez une function avant de la relier, puis lisez son journal une fois qu'elle s'exécute en conditions réelles.

Lancer une invocation de test

Pour lancer un test, la function doit avoir le statut Prêt : une function qui n'a pas été compilée avec succès n'a rien à exécuter.

Dans l'onglet Fonctions :

1. Sur la ligne de la function, sélectionnez Modifier.

   

2. Sélectionnez l'onglet Tester.

   

3. Sous Charger un exemple, choisissez un exemple d'entrée.

   

   L'éditeur d'entrée se remplit avec un payload adapté au type de la function : une enveloppe d'événement complète pour tout type d'événement du catalogue, ou l'entrée typée du point d'accroche.

4. (Facultatif) Modifiez le payload, puis sélectionnez Formater le JSON pour le remettre en forme.

   

   L'éditeur valide le JSON pendant la saisie et signale la ligne fautive s'il ne peut pas l'analyser.

5. Sélectionnez Lancer le test.

   

   Vous pouvez laisser le champ Délai d'expiration personnalisé (ms) vide : un test utilise toujours le délai configuré sur la function.

Ce que vous voyez dépend du type :

• Les functions de type Événement de la plateforme affichent un badge de code de sortie, la durée, l'ID de requête et la sortie. Un code de sortie 0 sans erreur signifie un succès. La sortie n'est affichée que pour le débogage : en production, elle est ignorée. Pour produire un effet, une function doit donc passer par le SDK.
• Les functions de type Hook affichent la décision retournée par votre gestionnaire (continue ou deny), le code et le message en cas de refus, ainsi que l'objet de résultat fourni.

Tout ce que votre gestionnaire écrit avec console.log et ses variantes apparaît dans le panneau Journaux, sous le résultat, accompagné de quelques messages de la plateforme qui montrent le démarrage de l'environnement d'exécution et l'appel du gestionnaire.

Lire une violation de contrat de hook

Quand l'exécution d'un hook échoue, le résultat affiche un panneau Violation de contrat au lieu d'une décision. En production, la même exécution fait échouer l'opération.

Ce panneau apparaît quand votre gestionnaire lève une exception, ne retourne rien, utilise une décision autre que continue ou deny, ou retourne un champ result que le point d'accroche ne définit pas. Un simple objet { decision: "continue" } convient, et un refus avec un code vide est signalé comme DENIED.

Dans le journal d'exécution, une réponse mal formée affiche quand même le code de sortie 0, car l'exécution elle-même a réussi. Quand un hook bloque des opérations alors que ses exécutions semblent réussies, collez ici une entrée relevée dans le journal d'exécution, puis lancez le test.

Lire le journal d'exécution

L'onglet Exécutions liste les invocations réelles, les plus récentes en premier. C'est l'outil principal pour savoir si la function s'est exécutée, et ce qui s'est passé.

Les exécutions sont conservées 60 jours, puis expirent : relevez avant cette date ce dont vous avez besoin pour une analyse post-mortem. Conservez aussi chaque version de votre gestionnaire dans votre propre dépôt : la plateforme suit un numéro de version et l'artefact compilé, pas l'historique de votre code source. C'est votre dépôt qui vous permet de restaurer la version précédente. Le bouton Charger plus affiche 20 lignes de plus, et le bouton Actualiser récupère les plus récentes. Tant qu'il en reste, le compteur à côté du titre Exécutions affiche 20+, puis 40+ ; une fois tout chargé, il indique le total exact.

Sélectionnez une ligne pour ouvrir sa vue détaillée, qui présente en plus tout ce que la plateforme a conservé :

• L'entrée et la sortie telles que stockées, plafonnées à 256 Ko chacune. Quand l'une était plus longue, un bandeau indique les tailles d'origine.
• Le SHA du WASM : la version compilée qui s'est réellement exécutée. C'est ainsi que vous distinguez « mon nouveau code est cassé » de « l'ancienne version tourne encore ».
• Les journaux complets, ou une mention de troncature quand votre gestionnaire a écrit plus de journaux que la capture n'en accepte.
• Les Métriques de trace, dans une section repliable : le nombre d'appels SDK de l'exécution, la mémoire utilisée, et la répartition du temps entre l'attente du démarrage, la préparation de l'exécution et l'exécution de votre code.

Si une function vous semble lente, consultez les métriques de trace avant de toucher à votre code. Le temps qu'OmniLab passe à préparer la première exécution après une modification ne dépend pas de votre gestionnaire et n'est pas décompté de votre délai. Seul le temps attribué à votre propre code peut être amélioré de votre côté.

En cas de problème

Toujours bloqué ?

Envoyez au support l'ID de requête de l'exécution en échec et l'ID du build de l'onglet Construire. Les exécutions expirent au bout de 60 jours : faites d'ici là une capture de la vue détaillée, avec l'entrée, l'erreur et les métriques de trace.

Étapes suivantes

• Configurer l'exécution et les secrets
• Functions de type hook
• Référence du SDK des functions