# Come si sostituiscono polling e webhook delle prediction Replicate in un'app esistente? > Inserisci un record di job asincrono indipendente dal provider tra il prodotto e l'API. Fai convergere webhook verificati e un worker di polling limitato sullo stesso finalizzatore idempotente, normalizza gli stati e copia i file in uno storage durevole. Inserisci un livello di job indipendente dal provider tra l'app e l'API. Normalizza creazione, stato, annullamento, eventi di completamento e conservazione degli output, così il prodotto non dipende da oggetti o URL Replicate. Non limitarti a cambiare una callback URL. Definisci prima il contratto asincrono necessario. ## Documenta il comportamento attuale La creazione asincrona Replicate restituisce ID, stato e URL ausiliari. L'app può interrogare `urls.get`, ricevere POST webhook o usare eventi server. Registra il percorso di ogni flusso e l'azione a ogni transizione. | Concetto Replicate | Sostituzione applicativa | |---|---| | ID prediction | ID job del provider e ID interno | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | Metodo di stato dell'adattatore | | Payload webhook | Evento di completamento normalizzato | | URL di output | Asset persistente dell'applicazione | Conserva lo stato grezzo separato da quello normalizzato per diagnosticare differenze nel ciclo di vita. ## Introduci un record interno Crea la riga nel database prima di chiamare il nuovo provider: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` Usa il `job_id` interno nell'interfaccia, nelle code e nelle notifiche. Aggiungi l'ID esterno dopo la creazione. Una chiave di idempotenza impedisce due job a pagamento dopo un errore di rete. ## Sostituisci il polling con un worker limitato Se il target consente di leggere i job ma non offre webhook, sposta il polling in un worker. Usa backoff esponenziale con jitter, scadenza e intervallo massimo. Fermati a ogni stato terminale, incluso l'annullamento. Non interrogare dal browser. Un worker server sopravvive alla chiusura della scheda, centralizza i limiti e salva le transizioni in transazioni. ## Sostituisci i webhook con eventi verificati Mantieni piccolo il gestore: * verifica firma o segreto prima del parsing; * deduplica per evento o per job e stato; * rispondi rapidamente e accoda l'elaborazione; * recupera il job ufficiale se il payload è parziale; * accetta consegne ripetute e fuori ordine. Replicate filtra start, output, logs e completed. Il target può inviare solo eventi terminali. Non inventare una precisione di avanzamento. ## Usa un'unica via di completamento Polling e webhook chiamano lo stesso finalizzatore idempotente. Blocca il job, verifica l'ID esterno, salva lo stato terminale, copia i file in storage durevole ed emette un solo evento. Così webhook e ultima lettura simultanei non generano notifiche doppie. ## Conserva i file prima che scompaiano Replicate documenta che i file di input e output delle prediction API vengono eliminati dopo un periodo limitato. Il target può usare una conservazione o una durata URL diversa. Tratta gli URL esterni come consegna, non come storage. Scarica subito gli output, valida tipo e dimensione, analizzali se necessario, salvali con una chiave propria e registra le checksum. Fornisci ai client un URL stabile tuo. ## Testa guasti e recupero Copri creazione ritardata, webhook duplicati o mancanti, 429 e 5xx, corse di annullamento, URL scaduti, payload invalidi e riavvio del worker durante un job. Esegui entrambi gli adattatori in shadow con input sicuri. Confronta stati terminali e asset prima di migrare una piccola quota di produzione. ## In sintesi La sostituzione durevole è un contratto interno di job asincrono, non callback sparse. Normalizza gli stati, finalizza in modo idempotente, conserva subito i file e indirizza webhook verificati o un worker limitato alla stessa via di completamento. ## FAQ ### Il browser deve interrogare direttamente l'API sostitutiva? È preferibile un worker lato server. Continua dopo la chiusura del browser, centralizza limiti e tentativi e aggiorna lo stato interno in modo coerente. ### Come si mappano gli stati delle prediction Replicate? Mappali su un ciclo interno ridotto, come creating, queued, running, completed, failed e canceled, mantenendo lo stato grezzo per il debug. ### Come si evita la doppia elaborazione di un webhook? Verifica l'autenticità, deduplica per evento o per job e stato e indirizza webhook e polling allo stesso finalizzatore transazionale idempotente. ### Cosa fare se il nuovo provider non offre webhook? Usa un worker in background con backoff esponenziale, jitter, scadenza e gestione esplicita di tutti gli stati terminali. ### Posso esporre permanentemente gli URL di output del provider? Non considerarli durevoli. Scarica rapidamente gli output e fornisci URL di asset propri con i tuoi controlli di accesso. ### Quali guasti devono coprire i test? Includi eventi duplicati o persi, limiti, errori temporanei, corse di annullamento, output scaduti, payload non validi e riavvii del worker.