En timeout visar att klienten inte fick det förväntade svaret i tid. Den bevisar inte ensam om den avsedda kampanjändringen genomfördes. Om nästa rad bara säger ”omförsök misslyckades” kan operatören sakna tillräckligt underlag för att förstå båda försöken och välja rätt efterkontroll.
En fellogg för ChatGPT-annonsering ska beskriva vad integrationen försökte åstadkomma, vilka anrop som gjordes och vilket underlag som finns för slutläget. Den här guiden gäller dokumentationen av förloppet. Den är inte en generell regel för omförsök mot alla endpoints och ersätter inte aktuell dokumentation för den operation som används.
Skilj en avsikt från flera försök
Skapa en intern operationsreferens innan det första anropet skickas. Behåll referensen för försök som hör till samma avsedda ändring. Ge varje anropsförsök ett eget löpnummer eller en egen identifierare så att tider, svar och transportfel går att skilja åt i efterhand.
”Skapa den godkända lanseringskampanjen” är exempelvis en avsikt. Ett första anrop med osäkert svar och ett senare dokumenterat omförsök är två försök. Ett efterföljande önskemål att ändra den godkända budgeten är en annan avsikt, även om det gäller samma kampanj och hanteras av samma integration.
Uppdelningen gör även summeringar mer rättvisande. Tio loggrader behöver inte betyda tio kampanjändringar. Det kan vara försök, statusfrågor och kontroller kring en enda ändring. Märk varje rads funktion så att den som felsöker inte måste gissa sammanhanget enbart från vilken endpoint som anropades.
Välj fält som besvarar bestämda frågor
Börja med en uttrycklig lista över tillåtna loggfält. Användbara uppgifter kan vara operationsreferens, försöksidentifierare, anropstid, varaktighet, metod, endpointmönster, kontoreferens, berörd resursidentifierare, svarsstatus och eventuell diagnostisk anropsidentifierare i svaret. Ta bara med uppgifter som den aktuella implementationen faktiskt får eller själv styr över.
Spara operationens godkända indata i ett lämpligt skyddat underlag, eller bevara en säker hänvisning dit. Den vanliga loggen kanske bara behöver en rensad sammanfattning eller ett fingeravtryck som skiljer versioner av indatan åt. Ett fingeravtryck hjälper vid versionsjämförelse men förklarar inte affärsinnebörden och ersätter inte det ordnade beslutsunderlaget.
| Fråga | Underlag som behöver finnas |
|---|---|
| Var det samma avsedda ändring? | Intern operationsreferens |
| Vilket försök fick timeout? | Försökets identitet och tidsuppgifter |
| Ändrades det inskickade innehållet? | Säker referens till indataversionen |
| Vad svarade servern? | Status och relevanta diagnostiska uppgifter |
| Vad finns i kontot nu? | Separat observation från efterkontrollen |
Använd enhetliga tidszoner och enheter. En varaktighet i millisekunder ska inte hamna i en kolumn märkt sekunder. Om tidsuppgifter kommer från olika system bör deras ursprung framgå. Utgå inte från att alla klockor ger en perfekt inbördes ordning när händelseförloppet rekonstrueras efter ett fel.
Låt osäkerheten finnas kvar
Skilj ett lokalt valideringsfel från ett känt serveravslag, ett avbrott i överföringen och ett bekräftat lyckat svar. Kategorierna leder till olika undersökningar. Ett anrop som aldrig lämnade klienten är inte samma situation som ett anrop vars svar försvann efter att servern kan ha behandlat det.
Om utfallet är osäkert ska det stå så tills en relevant efterkontroll ger mer information. En senare läsning av resursen eller ett jobbresultat kan klargöra läget, men ska dokumenteras som nytt underlag. Skriv inte tyst om den ursprungliga timeoutraden till ett lyckat resultat så att historiken över vad operatören visste försvinner.
OpenAI:s kampanjguide skiljer en osäker inlämning av ett bulkjobb från ett avslutat misslyckat jobb. Upprepa en osäker inlämning med samma jobbnyckel och identiskt innehåll. För ett avslutat misslyckat jobb ska operationsresultaten granskas, skapandeoperationernas nycklar behållas och en ny jobbnyckel användas enligt den dokumenterade rutinen. Bevara referenserna och eventuella omförsöksanvisningar i loggen. Reglerna innebär inget generellt löfte om hur omförsök fungerar för alla endpoints.
För asynkront arbete behöver ett accepterat jobb skiljas från de färdiga resultaten för varje operation. Knyt jobbreferens och senare observationer till den ursprungliga avsikten. Annars kan en accepterad inlämning beskrivas som om alla kampanjändringar redan har genomförts, trots att det slutliga utfallet ännu inte har kontrollerats.
En avsikt, flera observationer
- Operation K1
Skapa en godkänd kampanj med dokumenterad indataversion.
- Försök 1: osäkert svar
Spara försöksidentitet, tid och observerat transportfel.
Att ompröva - Efterkontroll
Dokumentera vad resurs- eller jobbkontrollen faktiskt visar.
Kontrollpunkt
Uteslut hemligheter innan loggen skrivs
Logga inte auktoriseringshuvuden, API-nycklar eller fullständiga miljödumpar. Rensa vid själva loggningen i stället för att förlita er på att en kollega tar bort hemligheter före vidarebefordran. Felobjekt kan innehålla mer sammanhang än väntat. Att serialisera hela objektet behöver därför vara ett medvetet och granskat val.
Granska även webbadresser och indatafält. En målwebbadress kan innehålla identifierare eller annan information som inte behövs för att förstå anropsfelet. Behåll det som besvarar felsökningsfrågan. Mer detaljerat underlag ska bara lagras där ansvariga personer har lämplig åtkomst och där organisationens hantering av sådant material kan följas.
Samma princip gäller skärmbilder och kopierad konsolutmatning. En väl rensad programlogg hjälper föga om en bilaga visar en nyckel bredvid felmeddelandet. Granska felsökningspaketet som en helhet innan det delas utanför teamet, och kontrollera att det är rätt kund och konto som beskrivs i materialet.
Använd förloppet för att välja nästa kontroll
Operatören ska kunna gruppera försök efter avsikt, hitta det ännu oklara utfallet och se vilken kontroll som kan ge nästa svar. Om dubbla resurser misstänks används utredningen av dubblerade kampanjer i stället för att skapandeanropet skickas igen på chans.
För rapporthämtning behandlar kontrollen av paginering fullständigheten utöver om enskilda anrop lyckades. Återkommande driftproblem kan följas upp i en incidentgenomgång. Kontrollera aktuella anropsregler i OpenAI:s kampanjdokumentation. En användbar logg minskar gissningarna om förloppet utan att påstå sådant som ingen observation har bekräftat.
Källor och avgränsning
Dokumentera logiska operationer och enskilda anropsförsök så att osäkra svar, omförsök och efterkontroller kan felsökas utan att hemligheter sprids.
Arbetsmetoder och exempel är redaktionella förslag. Kontrollera aktuella plattformsvillkor och funktioner inför genomförandet.