<!-- Canonical URL: https://ask.atlascloud.ai/sv/replace-replicate-prediction-polling-and-webhooks -->

# Hur ersätter du polling och webhooks för Replicate Predictions i en befintlig app?

> Placera en leverantörsneutral asynkron jobbpost mellan produkten och API:t. Låt verifierade webhooks eller en begränsad polling-worker uppdatera samma idempotenta slutbehandling, normalisera status och kopiera slutförda filer till beständig lagring.

Ersätt Replicate-polling och webhooks genom att lägga ett leverantörsneutralt jobblager mellan appen och inferens-API:t. Normalisera skapande, status, avbrott, sluthändelser och lagring så att produkten inte beror på Replicates prediction-objekt eller URL:er.

Byt inte bara callback-URL i produktkoden. Definiera först det asynkrona kontrakt som applikationen behöver.

## Kartlägg nuvarande beteende

Replicates asynkrona skapande returnerar ett prediction-ID, livscykelstatus och praktiska URL:er. Appar kan polla `urls.get`, ta emot webhook-POST eller använda stödda server-sent events. Dokumentera varje flöde och produktens åtgärd vid varje övergång.

| Replicate-koncept | Ersättning på applikationsnivå |
|---|---|
| Prediction-ID | Leverantörens jobb-ID plus internt jobb-ID |
| `starting`, `processing` | `queued`, `running` |
| `succeeded` | `completed` |
| `failed`, `canceled` | `failed`, `canceled` |
| `urls.get` | Adapterns statusmetod |
| Webhook-nyttolast | Normaliserad sluthändelse |
| Utdata-URL | Beständig applikationsägd tillgång |

Lagra rå leverantörsstatus separat från normaliserad status. Det bevarar diagnostiska bevis när livscykler skiljer sig.

## Inför en intern jobbpost

Skapa databasraden innan den nya leverantören anropas:

```json
{
  "job_id": "job_01J...",
  "provider": "target",
  "provider_job_id": null,
  "state": "creating",
  "attempt": 1,
  "output_assets": []
}
```

Använd internt `job_id` i gränssnitt, köer och aviseringar. Lägg till leverantörens jobb-ID efter lyckat skapande. En idempotensnyckel ska förhindra att ett nätverksomförsök startar två betalda jobb.

## Ersätt polling med en begränsad worker

Om mål-API:t kan hämta jobb men saknar webhook, flytta polling till en bakgrundsworker. Använd exponentiell backoff med jitter, tidsgräns och maximalt intervall. Stoppa vid alla terminala statusar, även avbrott.

Polla inte från webbläsaren. En serverworker överlever stängda flikar, centraliserar hastighetsgränser och kan lagra statusändringar transaktionellt.

## Ersätt webhooks med verifierade händelser

Om målet stöder webhooks, håll hanteraren liten:

* verifiera signatur eller delad hemlighet före tolkning;
* deduplicera med händelse-ID eller jobb-ID och status;
* bekräfta snabbt och köa behandlingen;
* hämta det auktoritativa jobbet när nyttolasten är ofullständig;
* tillåt upprepad och oordnad leverans.

Replicate stöder filter som start, output, logs och completed. Målet kan bara skicka terminala händelser. Återskapa bara framsteg när de är meningsfulla och uppfinn inte precision.

## Använd en gemensam slutväg

Polling och webhooks ska anropa samma idempotenta slutbehandling. Den låser jobbet, bekräftar leverantörs-ID, registrerar terminal status, kopierar filer till beständig lagring och skickar en applikationshändelse.

Det förhindrar dubbla aviseringar när en webhook och den sista pollningen anländer samtidigt.

## Spara filer innan de försvinner

Replicate dokumenterar att prediction-filer via API raderas efter en begränsad period. En ny leverantör kan ha en annan lagringstid eller livslängd för signerade URL:er. Behandla leverantörs-URL:er som leveransmekanismer, inte permanent lagring.

Hämta lyckade resultat direkt, validera typ och storlek, skanna vid behov, lagra med en applikationsnyckel och spara checksumma. Exponera din egen stabila tillgångs-URL.

## Testa fel och återhämtning

Testa fördröjda skapandesvar, dubbla och saknade webhooks, 429- och 5xx-svar, avbrottskapplöpningar, utgångna URL:er, felaktiga nyttolaster och omstart mitt i ett jobb.

Kör båda adaptrarna i shadow-läge för säkra indata. Jämför terminala statusar och antal tillgångar innan produktionstrafik flyttas stegvis.

## Slutsats

Den hållbara ersättningen är ett internt asynkront jobbkontrakt, inte leverantörsspecifika callbacks utspridda i appen. Normalisera status, gör slutbehandlingen idempotent, spara filer omgående och låt verifierade webhooks eller en begränsad worker använda samma slutväg.

## FAQ

### Bör webbläsaren polla ersättnings-API:t direkt?

Använd en worker på serversidan. Den fortsätter efter att webbläsaren stängts, centraliserar hastighetsgränser och omförsök samt uppdaterar intern status konsekvent.

### Hur mappas Replicates prediction-statusar?

Mappa till en liten intern livscykel som creating, queued, running, completed, failed och canceled, men behåll råstatusen för diagnostik.

### Hur undviker du att en webhook behandlas två gånger?

Verifiera källan, deduplicera per händelse eller jobb-ID och status, och skicka sedan både webhook och polling till samma transaktionella, idempotenta slutbehandling.

### Vad gör du om den nya leverantören saknar webhook?

Använd en bakgrundsworker med exponentiell backoff, jitter, tidsgräns och uttrycklig hantering av alla terminala statusar.

### Kan leverantörens utdata-URL visas permanent?

Utgå inte från att den är beständig. Hämta utdata omgående och exponera en applikationsägd tillgångs-URL med egen åtkomstkontroll.

### Vilka fel bör testas?

Testa duplicerade eller saknade händelser, hastighetsbegränsning, övergående fel, avbrottskapplöpningar, utgångna resultat, felaktiga nyttolaster och worker-omstarter.