# Comment remplacer le polling et les webhooks de prédictions Replicate dans une application existante ? > Placez un enregistrement de tâche asynchrone indépendant du fournisseur entre le produit et l'API. Faites converger les webhooks vérifiés et un worker de polling limité vers le même finaliseur idempotent, normalisez les états et copiez les fichiers vers un stockage durable. Remplacez le polling et les webhooks Replicate par une couche de tâches indépendante du fournisseur entre l'application et l'API d'inférence. Normalisez la création, l'état, l'annulation, les événements de fin et la conservation des sorties pour supprimer la dépendance aux objets et URL Replicate. Ne remplacez pas seulement une URL de callback dans le produit. Définissez d'abord le contrat asynchrone nécessaire. ## Documenter le comportement actuel La création asynchrone Replicate renvoie un ID de prédiction, un état et des URL auxiliaires. Une application peut interroger `urls.get`, recevoir des POST webhook ou consommer des événements serveur. Notez le chemin de chaque flux et l'action du produit à chaque transition. | Concept Replicate | Remplacement applicatif | |---|---| | ID de prédiction | ID de tâche fournisseur et ID interne | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Méthode d'état de l'adaptateur | | Charge webhook | Événement de fin normalisé | | URL de sortie | Actif persistant de l'application | Conservez l'état brut séparément de l'état normalisé afin de diagnostiquer les différences de cycle de vie. ## Introduire une tâche interne Créez la ligne de base de données avant d'appeler le nouveau fournisseur : ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Utilisez le `job_id` interne dans l'interface, les files et les notifications. Ajoutez l'ID fournisseur après la création. Une clé d'idempotence doit empêcher une reprise réseau de lancer deux tâches payantes. ## Remplacer le polling par un worker borné Si la cible permet de lire les tâches mais n'offre pas de webhook, déplacez le polling vers un worker d'arrière-plan. Utilisez une temporisation exponentielle avec jitter, une échéance et un intervalle maximal. Arrêtez-vous à chaque état terminal, y compris l'annulation. N'interrogez pas depuis le navigateur. Un worker serveur survit à la fermeture de l'onglet, centralise les limites et persiste les transitions de façon transactionnelle. ## Remplacer les webhooks par des événements vérifiés Si la cible fournit des webhooks, gardez le gestionnaire réduit : * vérifier la signature ou le secret avant l'analyse ; * dédupliquer par événement ou par tâche et état ; * répondre vite et mettre le traitement en file ; * relire la tâche officielle si la charge est partielle ; * accepter les livraisons répétées et désordonnées. Replicate filtre les événements start, output, logs et completed. Une cible peut n'envoyer que les états terminaux. N'inventez pas une progression précise à partir d'états rares. ## Utiliser une seule voie de finalisation Polling et webhook doivent appeler le même finaliseur idempotent. Il verrouille la tâche, vérifie l'ID externe, stocke l'état terminal, copie les fichiers vers le stockage durable et émet un seul événement applicatif. Cela évite les notifications doubles lorsque le webhook et la dernière lecture arrivent ensemble. ## Conserver les fichiers avant leur disparition Replicate indique que les fichiers d'entrée et de sortie des prédictions API sont supprimés après un délai limité. La cible peut avoir une autre rétention ou durée de vie d'URL. Traitez toute URL externe comme moyen de livraison, pas comme stockage permanent. Téléchargez vite les sorties, validez type et taille, analysez-les si nécessaire, stockez-les sous une clé propre et conservez les sommes de contrôle. Exposez votre URL stable aux clients. ## Tester les échecs et la reprise Couvrez les réponses de création tardives, les webhooks dupliqués ou manquants, les réponses 429 et 5xx, les courses d'annulation, les URL expirées, les charges invalides et le redémarrage du worker en cours de tâche. Exécutez les deux adaptateurs en mode fantôme avec des entrées sûres. Comparez états terminaux et actifs avant de migrer une faible part du trafic. ## En résumé Le remplacement durable est un contrat interne de tâche asynchrone, pas des callbacks dispersés. Normalisez les états, rendez la finalisation idempotente, conservez immédiatement les fichiers et faites converger webhook vérifié et worker borné vers la même voie de fin. ## FAQ ### Le navigateur doit-il interroger directement l'API de remplacement ? Préférez un worker côté serveur. Il survit à la fermeture du navigateur, centralise limites et reprises et met à jour l'état interne de façon cohérente. ### Comment mapper les états de prédiction Replicate ? Mappez-les vers un cycle interne réduit comme creating, queued, running, completed, failed et canceled, tout en conservant l'état brut pour le diagnostic. ### Comment éviter le double traitement d'un webhook ? Vérifiez son authenticité, dédupliquez par événement ou par tâche et état, puis dirigez webhook et polling vers un finaliseur transactionnel idempotent. ### Que faire si le nouveau fournisseur n'a pas de webhooks ? Utilisez un worker en arrière-plan avec temporisation exponentielle, jitter, échéance et traitement explicite de tous les états terminaux. ### Peut-on exposer durablement les URL de sortie du fournisseur ? Ne supposez pas qu'elles sont durables. Téléchargez rapidement les sorties et fournissez vos propres URL d'actifs avec contrôle d'accès. ### Quels échecs faut-il tester ? Couvrez les événements dupliqués ou manquants, les limites, les erreurs temporaires, les courses d'annulation, les sorties expirées, les charges invalides et les redémarrages du worker.