La sincronizzazione incrementale dovrebbe essere in grado di interrompersi a metà pagina e riavviarsi senza perdere prove. Il caso difficile non è il primo download riuscito. È il timeout dopo l'archiviazione, la consegna duplicata dopo il riavvio e il report che arriva dopo la fine del periodo di reporting apparente.
Definire l'unità di identità
Utilizzare l'identità del report documentata del provider e conservarne il contesto tenant e reporter. Gli ID report non devono essere considerati univoci a livello globale tra clienti o origini. Memorizza un'impronta digitale del payload di origine insieme all'identità. Una ripetizione identica può essere trattata come un duplicato; la stessa identità con byte diversi dovrebbe essere indagata o gestita attraverso un modello di revisione documentato.
RFC 9990 fornisce la struttura e la semantica di rapporti aggregati. Conservare separatamente i periodi di reporting originali e gli orari di ricezione. La filigrana incrementale di un raccoglitore non dovrebbe reinterpretare silenziosamente un periodo di valutazione storico come un timestamp di arrivo.
Raccogli i dati e progredisci insieme
Recupera una pagina delimitata, convalida l'ambito e lo schema, scrivi i dati normalizzati con la loro provenienza e solo dopo avanza il punto di controllo. Preferisci una transazione che impegni i dati e proceda in modo atomico. Se questo non è disponibile, progetta per la riproduzione con un vincolo di unicità stabile. Un cursore salvato prima che i record siano durevoli crea una finestra di perdita.
Supponiamo che un collezionista memorizzi la prima pagina in modo duraturo ma si blocchi prima di far avanzare il suo indicatore di avanzamento. Al riavvio, potrebbe recuperare nuovamente la pagina. Un vincolo di identità stabile con ambito adeguato dovrebbe evitare di aggiungere ripetizioni esatte, consentendo al tempo stesso il commit della pagina successiva. Se l'indicatore di avanzamento fosse avanzato prima che i record diventassero durevoli, il riavvio potrebbe ignorare completamente le prove. Si tratta di stati di errore ipotetici, non di un file eseguito o di un test del database.
Se arriva un'identità ripetuta con byte di origine diversi, conservare l'originale e il conflitto per una decisione di revisione documentata. Un hash modificato è un segnale su cui indagare, non una prova che il messaggio conta come modificato: la formattazione o la normalizzazione possono influenzare anche i byte. Testare l'effettiva transazione di archiviazione, il ripristino in caso di arresto anomalo e il confronto dei byte di origine nell'implementazione approvata; questa guida non garantisce alcuna garanzia di durata.
Gestire i ritardi senza pretendere certezze
Utilizza una finestra di sovrapposizione limitata quando l'API effettiva supporta la ripetizione delle query sugli arrivi, quindi deduplica in base all'identità. Scegli la sovrapposizione utilizzando i ritardi di acquisizione osservati e le esigenze operative. Una sovrapposizione finita non può garantire la scoperta di dati arbitrariamente tardivi. Aggiungere una riconciliazione completa periodica o un altro meccanismo di recupero documentato e registrare la limitazione di copertura rimanente.
Mantieni gli emendamenti distinti dai duplicati esatti. Conserva entrambi gli hash in caso di conflitto ed evita che una sostituzione inspiegabile modifichi silenziosamente un rapporto cliente già emesso. Ricalcola i riepiloghi interessati in una nuova revisione quando viene accettata una correzione valida, con una traccia del risultato precedente.
Recuperare con il contratto di servizio reale
Rispetta i limiti di frequenza, Retry-After e l'impaginazione specifica della versione. Best practice per l'API di GitHub offrire un esempio concreto di comportamento di richiesta limitato e premuroso; non definiscono le quote del fornitore di autenticazione. Tratta un errore 429 o temporaneo come un motivo per mettere in pausa e riprovare all'interno della policy, non come un'autorizzazione per richieste parallele illimitate.
Monitora l'ultimo checkpoint riuscito, l'arrivo non elaborato più vecchio, l'esaurimento dei tentativi e i conflitti. Una risposta API sana con un cursore bloccato è ancora una sincronizzazione non riuscita. In caso di risultato ambiguo, ispezionare le identità memorizzate e i progressi prima di ritentare un passaggio con effetti collaterali. Conserva i byte di origine e il checkpoint precedente in modo che il ripristino sia basato sull'evidenza. Qui non viene dimostrata alcuna chiamata API, simulazione di nuovi tentativi o funzionalità di sincronizzazione EmailAuth . Documentazione sui limiti di velocità di GitHub rileva che potrebbe restituire 403 nonché 429 per i limiti di tasso; distinguere i segnali limite documentati dal rifiuto permanente dell'autorizzazione piuttosto che assegnare un significato a ogni stato.