:FAQ sur la méthode waitUntil

Une requête fetch peut échouer pour les raisons suivantes :

• Cycle de vie du contexte

  Lorsque vous appelez la méthode addEventListener pour enregistrer une fonction de rappel, le contexte est créé automatiquement. Une fois que l'objet Response (en-tête et corps de la réponse) renvoyé par la méthode event.respondWith a été lu, le contexte se ferme.

  Le cycle de vie de toutes les fonctions asynchrones s'inscrit dans celui des contextes. Une fonction asynchrone attend la résolution de l'objet Promise. Pour éviter cette attente, appelez la méthode event.waitUntil. Celle-ci prolonge le cycle de vie du contexte jusqu'à l'exécution de tous les objets Promise qui lui sont transmis.

• États partagés entre les contextes

  Les états ne peuvent pas être partagés entre les contextes. Les données qui n'utilisent pas de structures JavaScript standard ne sont pas partageables d'un contexte à l'autre. Par exemple, il est impossible de partager des données structurées selon l'API Service Worker ou des objets Stream entre différents contextes. Si le contexte A utilise un objet n'appartenant pas au contexte A, ER détecte cet objet et lève une exception.

  Remarque

  Pour partager des états, utilisez des objets JavaScript natifs (String, Array, Object, Number) ou des classes personnalisées.

• Objets Promise concurrents

  Les objets Promise non attendus par les fonctions s'exécutent de manière concurrente. Pour qu'ER réponde immédiatement aux navigateurs dès la réception des requêtes, sans attendre les sous-requêtes, appelez la méthode waitUntil afin de garantir le bon fonctionnement du programme.

• Exceptions levées par les fonctions asynchrones

  Si une sous-requête dans une instruction waitUntil lève une exception, le contexte se termine.

Vous pouvez appeler la méthode waitUntil à plusieurs reprises ou l'imbriquer. Ainsi, lorsque l'objet Promise renvoyé par l'une des méthodes waitUntil est résolu, vous pouvez continuer à appeler cette méthode dans la fonction de rappel.