Inkrementell synkronisering skal kunne stoppe halvveis gjennom en side og starte på nytt uten å miste bevis. Den vanskelige saken er ikke den første vellykkede nedlastingen. Det er tidsavbruddet etter lagring, duplikatleveringen etter omstart og rapporten som kommer etter at den tilsynelatende rapporteringsperioden er over.
Definer enheten for identitet
Bruk leverandørens dokumenterte rapportidentitet og behold leietaker- og reporterkonteksten. Rapport-ID-er bør ikke antas globalt unike på tvers av kunder eller kilder. Lagre et kildenyttelastfingeravtrykk ved siden av identiteten. En identisk gjentakelse kan behandles som et duplikat; samme identitet med forskjellige byte bør undersøkes eller håndteres gjennom en dokumentert revisjonsmodell.
RFC 9990 gir strukturen og semantikken til samlede rapporter. Oppbevar originale rapporteringsperioder og mottakstider separat. En samlerens inkrementelle vannmerke bør ikke stille omtolkning av en historisk evalueringsperiode som et ankomsttidsstempel.
Forplikte data og fremgang sammen
Hent en avgrenset side, valider omfanget og skjemaet, skriv de normaliserte dataene med dets opprinnelse og først deretter gå videre til sjekkpunktet. Foretrekk en transaksjon som forplikter dataene og fremskritt atomisk. Hvis det ikke er tilgjengelig, design for replay med en stabil unikhetsbegrensning. En markør som lagres før postene er holdbare, skaper et tapsvindu.
Anta at en samler lagrer side én varig, men krasjer før fremdriftsmarkøren. Ved omstart kan den hente siden igjen. En stabil identitetsbegrensning med riktig omfang bør unngå å legge til eksakte gjentakelser, samtidig som den tillater neste side å bli forpliktet. Hvis fremdriftsmarkøren hadde avansert før postene var holdbare, kunne omstart hoppe over bevis helt. Dette er hypotetiske feiltilstander, ikke en utført fil eller databasetest.
Hvis en gjentatt identitet kommer med forskjellige kildebyte, bevar originalen og konflikten for en dokumentert revisjonsavgjørelse. En endret hash er et signal om å undersøke, ikke et bevis på at meldingstallene endret: formatering eller normalisering kan også påvirke byte. Test selve lagringstransaksjonen, krasjgjenoppretting og kilde-byte-sammenligning under den godkjente implementeringen; denne veiledningen hevder ingen holdbarhetsgaranti.
Håndter forsinkelser uten å kreve sikkerhet
Bruk et avgrenset overlappingsvindu når den faktiske API-en støtter re-forespørsler om ankomster, og deduplisere deretter etter identitet. Velg overlappingen ved å bruke observerte inntaksforsinkelser og operasjonelle behov. En endelig overlapping kan ikke garantere oppdagelse av vilkårlig sene data. Legg til periodisk full avstemming eller en annen dokumentert utfyllingsmekanisme og registrer den gjenværende dekningsbegrensningen.
Hold endringer forskjellig fra eksakte duplikater. Behold begge hashene ved konflikt og forhindre at en uforklarlig erstatning i det stille endrer en allerede utstedt kunderapport. Beregn berørte sammendrag på nytt under en ny revisjon når en gyldig korreksjon er akseptert, med en sporing tilbake til forrige resultat.
Gjenopprett under den virkelige servicekontrakten
Respekter rategrenser, Prøv på nytt etter og versjonsspesifikk paginering. GitHubs beste fremgangsmåter for API gi et konkret eksempel på begrenset, hensynsfull forespørselsoppførsel; de definerer ikke en autentiseringsleverandørs kvoter. Behandle en 429 eller forbigående feil som en grunn til å sette på pause og prøve på nytt innenfor policyen, ikke som tillatelse for ubegrensede parallelle forespørsler.
Overvåk siste vellykkede sjekkpunkt, eldste ubehandlede ankomst, forsøk på nytt, utmattelse og konflikter. Et sunt API-svar med en fast markør er fortsatt en mislykket synkronisering. Ved et tvetydig utfall, inspiser lagrede identiteter og fremgang før du prøver på nytt et skritt som gir bivirkninger. Bevar kildebytes og det forrige sjekkpunktet slik at gjenoppretting er bevisstyrt. Ingen API-kall, simulering på nytt eller EmailAuth synkronisering demonstreres her. GitHubs hastighetsgrensedokumentasjon bemerker at det kan returnere 403 så vel som 429 for rategrenser; skille dokumenterte grensesignaler fra permanent autorisasjonsnektelse i stedet for å tildele én betydning til hver status.