# Hoe voorkom je dubbele videotaken wanneer een API-verzoek een time-out krijgt? > Voorkom duplicaten door iedere bedoelde uitvoer een stabiele operatiesleutel te geven, het verzoek vóór verzending op te slaan, gedocumenteerde provider-idempotentie te gebruiken en ambigue time-outs vóór retry te reconciliëren. Een time-out betekent onbekend, niet afgewezen. # Hoe voorkom je dubbele videotaken wanneer een API-verzoek een time-out krijgt? Een time-out bij verzending creëert een ambigue uitkomst. Het verzoek kan vóór de dienst zijn mislukt, zijn aangekomen en geweigerd, of een remote videotaak hebben gemaakt waarvan het antwoord de client nooit bereikte. Meteen opnieuw proberen kan één bedoelde clip veranderen in twee betaalde generaties. De oplossing is een idempotente operatielaag rond de video-API. Maak en bewaar eerst de bedoelde operatie, geef een stabiele sleutel, registreer elke poging en gebruik gedocumenteerde idempotentie of zoekmogelijkheden. Kan de remote uitkomst niet worden bewezen, zet de operatie dan expliciet op onbekend. ## Definieer één bedoelde bijwerking De sleutel moet identificeren wat de gebruiker wil creëren, niet één HTTP-poging. Krijgt iedere retry een nieuwe sleutel, dan kan de provider het duplicaat niet herkennen. Een catalogusoperatie kan worden bepaald door: * product-ID; * versie van creatieve template; * fingerprint van bronmedia; * promptversie; * locale; * beeldverhouding; * variantnaam. Maak een canonieke representatie met vaste volgorde en genormaliseerde waarden en bereken de hash. Bewaar leesbare dimensies daarnaast. Een opzettelijk nieuwe generatie krijgt een nieuwe operatie of variant, ook bij dezelfde prompt. Genereer geen willekeurige UUID in de retrylus. Maak de sleutel vóór het eerste verzoek en hergebruik hem tot een eindstatus. ## Sla op vóór verzending De lokale database moet de operatie kennen vóór de netwerkcall. Dat is het write-aheadprincipe voor API-bijwerkingen. | Veld | Doel | |---|---| | Operatiesleutel | Voorkomt dubbele lokale intentie | | Verzoek-hash | Bewijst verzonden parameters | | Status | Onderscheidt voorbereid, verzonden, onbekend en compleet | | Aantal pogingen | Past begrensd retrybeleid toe | | Provider en model | Ondersteunt route en reconciliatie | | Remote taak-ID | Hervat polling zonder opnieuw verzenden | | Laatste fout | Bewaart diagnosecontext | | Uitvoerchecksum | Detecteert dubbele of gewijzigde assets | Stel een uniekheidsbeperking in. Twee workers die dezelfde operatie maken moeten op één record uitkomen. Claim het vóór verzending met atomaire update of lease. ## Gebruik provider-idempotentie alleen zoals gedocumenteerd Sommige API's accepteren een sleutel en retourneren bij herhaling het eerste geaccepteerde resultaat. Dat is het sterkste pad wanneer documentatie endpoint, bewaartermijn, parametervergelijking en foutgedrag beschrijft. Controleer: * of het video-endpoint de sleutel ondersteunt; * hoe lang de provider die onthoudt; * of dezelfde sleutel met andere parameters wordt geweigerd; * of retries de oorspronkelijke remote-ID teruggeven. Neem niet aan dat een header voor betalingen of synchrone tekst ook geldt voor asynchroon video. Een OpenAI-compatibele verzoekvorm maakt providerspecifieke taakcreatie niet automatisch idempotent. ## Behandel time-outs als onbekende uitkomsten | Status | Bewijs | Volgende actie | |---|---|---| | `prepared` | Lokaal record, verzending niet gestart | Verzend | | `sending` | Worker begon verzoek | Wacht op resultaat of time-out | | `accepted` | Remote-ID ontvangen | Poll | | `unknown` | Time-out zonder bevestiging | Reconcileer | | `failed` | Expliciete weigering of eindfout | Pas foutbeleid toe | | `complete` | Uitvoer duurzaam opgeslagen | Retourneer bestaand resultaat | Het verschil tussen `unknown` en `failed` is essentieel. Een netwerkuitzondering zegt iets over de clientverbinding, niet noodzakelijk over het werk van de provider. Voeg de lokale sleutel toe aan providermetadata als een clientreferentie beschikbaar is, zodat later op een stabiele waarde kan worden gezocht. ## Reconcileer vóór retry Een reconciliatieworker onderzoekt de onbekende operatie: 1. Controleer of vóór de crash een remote-ID is opgeslagen. 2. Zoek op sleutel of clientreferentie indien ondersteund. 3. Doorzoek een begrensde takenlijst op tijd, model en fingerprint. 4. Bekijk webhooks die na de time-out kwamen. 5. Vergelijk gebruiks- of factureringsevents indien tijdig beschikbaar. 6. Probeer alleen opnieuw bij bewezen afwezigheid of veilige gedocumenteerde idempotentie. Alleen tijd en prompt kunnen valse matches geven. Gebruik meerdere kenmerken en stuur onzekere overeenkomsten naar review. Zonder lookup of garantie kan het juiste beleid wachten, risico accepteren of een menselijke beslissing zijn. ## Scheid transportretries van generatieretries HTTP-bibliotheken herhalen netwerkfouten soms automatisch. Dat is nuttig voor veilige reads maar gevaarlijk voor verzending met bijwerkingen. Schakel generieke POST-retries uit tenzij de operatie door een stabiele sleutel en documentatie wordt beschermd. Gebruik twee tellers: * transportpogingen om dezelfde beschermde operatie te verzenden; * generatiepogingen voor een vervangende uitvoer na eindfout of kwaliteitsafwijzing. Een transportretry moet op dezelfde remote taak uitkomen. Een generatieretry is een nieuwe betaalde creatieve poging met eigen identiteit, gekoppeld aan de oorspronkelijke taak. ## Beheer gelijktijdige workers met een lease Time-outs zijn niet de enige bron. Twee workers kunnen hetzelfde item kiezen, of een trage worker kan na lockverval doorgaan. Claim werk met een atomaire lease met eigenaar, begintijd en vervaldatum. Controleer vóór verzending eigendom en dat geen remote taak is vastgelegd. Sla de remote-ID op via transactie of conditionele update die faalt als een andere worker al verder is. Gebruik fencing tokens als een verouderde worker nog kan schrijven. Elke lease verhoogt een versie; de database accepteert alleen de nieuwste. ## Laat webhooks en polling convergeren Video is asynchroon, dus polling en webhooks kunnen dezelfde overgang melden. Ook handlers moeten idempotent zijn. Dedupliceer op event-ID en update voorwaardelijk: `processing` mag `complete` niet terugzetten. Dubbele downloads schrijven naar een deterministische tijdelijke sleutel, verifiëren checksum en komen uit op één definitief object. ```text ontvang voltooiing zoek operatie via remote-ID kopieer uitvoer naar deterministische sleutel verifieer media en checksum registreer duurzame URI markeer compleet indien nog niet gedaan ``` Na een crash kan de volgende handler hervatten zonder nieuwe video. ## Log voldoende bewijs voor audit Bewaar per poging tijdstempels, time-outtype, verzoek-hash, idempotentiesleutel, antwoordheaders, remote-ID en retrybesluit. Redigeer geheimen. | Metric | Wat die toont | |---|---| | Onbekende verzendingen | Netwerk- of providerambiguïteit | | Gereconcilieerd zonder retry | Succesvol vermeden duplicaten | | Beschermde retries | Idempotentie bij storingen | | Verdachte dubbele taken | Resterend financieel risico | | Dubbele checksum | Zelfde of herhaald resultaat | | Tijd in unknown | Herstelsnelheid | Waarschuw bij stijging voordat retrylimieten worden verhoogd. Netwerkproblemen plus agressieve retries kunnen kosten snel vermenigvuldigen. ## Verberg providergedrag achter een adapter Een multimodel-app moet één interne verzendinterface met capaciteitsvlaggen bieden. De adapter beheert schema, idempotentie, lookup, statusmapping en uitvoerextractie. [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=avoid-duplicate-video-jobs-api-timeout) kan integratiewerk voor tekst-, beeld- en videomodellen via één OpenAI-compatibel platform verminderen. Controleer toch het exacte model en endpoint: compatibiliteit is geen universele belofte over asynchrone idempotentie. Retourneer een genormaliseerde uitkomst: geaccepteerd met ID, expliciet geweigerd of onbekend. Maak van transportuitzonderingen geen providerfouten. ## Test ambigue gevallen bewust Het positieve pad bewijst geen veiligheid. Injecteer in staging fouten vóór verzending, nadat bytes vertrekken, na acceptatie, na antwoord vóór database-update en tijdens webhooklevering. Met provider-idempotentie moet één operatie hoogstens één remote taak maken. Zonder moet ze `unknown` worden, automatische herverzending pauzeren en genoeg bewijs tonen. Test gelijktijdige workers, verlopen leases, vertraagde en herhaalde webhooks, procesherstarts en een oude sleutel met gewijzigde parameters. Dat is goedkoper dan dubbele generatie op een factuur ontdekken. ## Conclusie Voorkom dubbele videotaken door elke bedoelde uitvoer één permanente operatiesleutel te geven en de operatie van HTTP-pogingen te scheiden. Sla intentie op vóór verzending, gebruik gedocumenteerde idempotentie en behandel time-outs als onbekend en te reconciliëren. Leases, conditionele wijzigingen, idempotente voltooiing en duurzame logs maken retries gecontroleerd herstel in plaats van dubbele aankoop. ## FAQ ### Betekent een HTTP-time-out dat de video-API geen taak heeft gemaakt? Nee. De provider kan het verzoek hebben geaccepteerd en een taak hebben gemaakt, ook al ontving de client geen antwoord. Behandel de uitkomst als onbekend tot reconciliatie. ### Wat moet een idempotentiesleutel voorstellen? Eén bedoelde bijwerking, zoals product, templateversie, locale, beeldverhouding en variant. Hergebruik de sleutel bij retries van die operatie en maak een nieuwe voor werkelijk nieuwe uitvoer. ### Voorkomt een unieke databasebeperking alle duplicaten? Ze voorkomt dubbele lokale operaties, maar niet dat een provider twee verzoeken accepteert. Combineer met provider-idempotentie of reconciliatie. ### Moet een client elke time-out automatisch herhalen? Nee. Automatische retries zijn alleen veilig wanneer het verzoek idempotent is of de provideruitkomst kan worden vastgesteld. Zet anders de taak op onbekend en reconcileer eerst. ### Hoe lang moeten idempotentierecords worden bewaard? Minstens zo lang als retry-, providerzoek-, factuurgeschil- en auditvensters. Stem af op gedocumenteerd gedrag en bedrijfsrisico. ### Garandeert een OpenAI-compatibele API gelijke idempotentie voor alle videomodellen? Nee. Transport kan worden genormaliseerd, maar asynchrone taakcreatie en idempotentie kunnen model- of providerspecifiek blijven. Controleer actuele documentatie.