Incrementele synchronisatie zou halverwege een pagina moeten kunnen stoppen en opnieuw moeten starten zonder bewijsverlies. Het moeilijke geval is niet de eerste succesvolle download. Het gaat om de time-out na opslag, de dubbele levering na herstart en het rapport dat binnenkomt nadat de schijnbare rapportageperiode is verstreken.
Definieer de eenheid van identiteit
Gebruik de gedocumenteerde rapportidentiteit van de provider en behoud de tenant- en reportercontext. Rapport-ID's mogen niet worden aangenomen dat ze globaal uniek zijn voor klanten of bronnen. Bewaar een vingerafdruk van de bronpayload naast de identiteit. Een identieke herhaling kan als duplicaat worden behandeld; dezelfde identiteit met verschillende bytes moet worden onderzocht of afgehandeld via een gedocumenteerd revisiemodel.
RFC 9990 biedt de structuur en semantiek van geaggregeerde rapporten. Bewaar originele rapportageperioden en ontvangsttijden afzonderlijk. Het incrementele watermerk van een verzamelaar mag een historische evaluatieperiode niet stilzwijgend herinterpreteren als een tijdstempel van aankomst.
Data vastleggen en samen vooruitgang boeken
Haal een begrensde pagina op, valideer de reikwijdte en het schema, schrijf de genormaliseerde gegevens met hun herkomst en ga dan pas verder naar het controlepunt. Geef de voorkeur aan een transactie die de gegevens vastlegt en atomair verloopt. Als dat niet beschikbaar is, ontwerp dan voor herhaling met een stabiele uniciteitsbeperking. Een cursor die wordt opgeslagen voordat de records duurzaam zijn, creëert een verliesvenster.
Stel dat een verzamelaar pagina één duurzaam opslaat, maar crasht voordat hij zijn voortgangsmarkering verder zet. Bij het opnieuw opstarten kan het zijn dat de pagina opnieuw wordt opgehaald. Een correct gedefinieerde stabiele identiteitsbeperking moet het toevoegen van exacte herhalingen vermijden, terwijl de volgende pagina wel kan worden vastgelegd. Als de voortgangsmarkering vooruit was gegaan voordat de records duurzaam waren, zou het opnieuw opstarten het bewijs volledig kunnen overslaan. Dit zijn hypothetische fouttoestanden, geen uitgevoerde bestands- of databasetest.
Als er een herhaalde identiteit binnenkomt met verschillende bronbytes, bewaar dan het origineel en het conflict voor een gedocumenteerde herzieningsbeslissing. Een gewijzigde hash is een signaal om te onderzoeken, geen bewijs dat het aantal berichten is gewijzigd: opmaak of normalisatie kan ook van invloed zijn op bytes. Test de daadwerkelijke opslagtransactie, crashherstel en bron-byte-vergelijking onder de goedgekeurde implementatie; deze gids geeft geen duurzaamheidsgarantie.
Ga om met laattijdigheid zonder zekerheid te claimen
Gebruik een begrensd overlapvenster wanneer de daadwerkelijke API het opnieuw opvragen van aankomsten ondersteunt, en ontdubbel vervolgens op identiteit. Kies de overlap met behulp van waargenomen opnamevertragingen en operationele behoeften. Een eindige overlap kan de ontdekking van willekeurig late gegevens niet garanderen. Voeg periodieke volledige afstemming of een ander gedocumenteerd aanvullingsmechanisme toe en registreer de resterende dekkingsbeperking.
Houd wijzigingen gescheiden van exacte duplicaten. Behoud beide hashes bij conflicten en voorkom dat een onverklaarbare vervanging stilletjes een reeds uitgegeven klantrapport wijzigt. Bereken de getroffen samenvattingen opnieuw onder een nieuwe revisie wanneer een geldige correctie wordt geaccepteerd, met een tracering naar het vorige resultaat.
Herstel onder het echte servicecontract
Respecteer snelheidslimieten, Retry-After en versiespecifieke paginering. GitHub's API-best practices een concreet voorbeeld bieden van begrensd, attent verzoekgedrag; ze definiëren niet de quota's van een authenticatieleverancier. Beschouw een 429- of tijdelijke fout als reden om te onderbreken en opnieuw te proberen binnen het beleid, niet als toestemming voor onbeperkte parallelle verzoeken.
Bewaak het laatste succesvolle controlepunt, de oudste onverwerkte aankomst, uitputting van nieuwe pogingen en conflicten. Een gezond API-antwoord met een vastgelopen cursor is nog steeds een mislukte synchronisatie. Inspecteer bij een dubbelzinnige uitkomst de opgeslagen identiteiten en voortgang voordat u opnieuw een stap met neveneffecten probeert. Behoud bronbytes en het vorige controlepunt, zodat het herstel op bewijsmateriaal is gebaseerd. Er wordt hier geen API-aanroep, simulatie van opnieuw proberen of EmailAuth synchronisatie gedemonstreerd. GitHub's documentatie over snelheidslimieten merkt op dat het zowel 403 als 429 kan retourneren voor tarieflimieten; maak onderscheid tussen gedocumenteerde limietsignalen en permanente weigering van autorisatie in plaats van aan elke status één betekenis toe te kennen.