La synchronisation incrémentielle doit pouvoir s'arrêter au milieu d'une page et redémarrer sans perte de preuve. Le cas difficile n’est pas le premier téléchargement réussi. Il s'agit du délai d'attente après le stockage, de la livraison en double après le redémarrage et du rapport qui arrive après la fin de la période de reporting apparente.
Définir l'unité d'identité
Utilisez l’identité de rapport documentée du fournisseur et conservez son contexte de locataire et de rapporteur. Les ID de rapport ne doivent pas être considérés comme uniques à l’échelle mondiale parmi les clients ou les sources. Stockez une empreinte digitale de charge utile source à côté de l’identité. Une répétition identique peut être traitée comme un doublon ; la même identité avec des octets différents doit être étudiée ou traitée via un modèle de révision documenté.
RFC 9990 fournit la structure et la sémantique de rapports agrégés. Conservez séparément les périodes de reporting originales et les délais de réception. Le filigrane incrémentiel d'un collectionneur ne doit pas réinterpréter silencieusement une période d'évaluation historique comme un horodatage d'arrivée.
Engagez les données et progressez ensemble
Récupérez une page délimitée, validez la portée et le schéma, écrivez les données normalisées avec leur provenance et avancez ensuite seulement le point de contrôle. Préférez une transaction qui valide les données et progresse de manière atomique. Si cela n'est pas disponible, concevez pour la relecture avec une contrainte d'unicité stable. Un curseur enregistré avant que les enregistrements ne soient durables crée une fenêtre de perte.
Supposons qu'un collectionneur stocke la première page de manière durable mais plante avant d'avancer son marqueur de progression. Au redémarrage, il peut récupérer la page à nouveau. Une contrainte d'identité stable correctement étendue devrait éviter d'ajouter des répétitions exactes, tout en permettant la validation de la page suivante. Si le marqueur de progression avait avancé avant que les enregistrements ne soient durables, le redémarrage pourrait ignorer complètement les preuves. Il s’agit d’états de défaillance hypothétiques, et non d’un test de fichier ou de base de données exécuté.
Si une identité répétée arrive avec des octets sources différents, conservez l'original et le conflit pour une décision de révision documentée. Un hachage modifié est un signal à enquêter, et non une preuve que le nombre de messages a changé : le formatage ou la normalisation peuvent également affecter les octets. Testez la transaction de stockage réelle, la récupération après incident et la comparaison des octets sources dans le cadre de la mise en œuvre approuvée ; ce guide n'affirme aucune garantie de durabilité.
Gérer les retards sans prétendre à la certitude
Utilisez une fenêtre de chevauchement délimitée lorsque l'API réelle prend en charge la réinterrogation des arrivées, puis dupliquez par identité. Choisissez le chevauchement en fonction des délais d’ingestion observés et des besoins opérationnels. Un chevauchement fini ne peut garantir la découverte de données arbitrairement tardives. Ajoutez un rapprochement complet périodique ou un autre mécanisme de remplissage documenté et enregistrez la limite de couverture restante.
Gardez les modifications distinctes des doublons exacts. Conservez les deux hachages en cas de conflit et empêchez un remplacement inexpliqué de modifier silencieusement un rapport client déjà émis. Recalculez les résumés concernés sous une nouvelle révision lorsqu'une correction valide est acceptée, avec une trace jusqu'au résultat précédent.
Récupérer dans le cadre du contrat de service réel
Respectez les limites de débit, Retry-After et la pagination spécifique à la version. Meilleures pratiques API de GitHub offrir un exemple concret de comportement de demande limité et attentionné ; ils ne définissent pas les quotas d'un fournisseur d'authentification. Traitez un 429 ou un échec passager comme une raison de faire une pause et de réessayer dans le cadre de la stratégie, et non comme une autorisation pour des requêtes parallèles illimitées.
Surveillez le dernier point de contrôle réussi, la plus ancienne arrivée non traitée, réessayez l'épuisement et les conflits. Une réponse API saine avec un curseur bloqué reste un échec de synchronisation. En cas de résultat ambigu, inspectez les identités stockées et la progression avant de réessayer une étape à effets secondaires. Préservez les octets sources et le point de contrôle précédent afin que la récupération soit fondée sur des preuves. Aucun appel API, simulation de nouvelle tentative ou capacité de synchronisation EmailAuth n'est démontré ici. Documentation sur les limites de débit de GitHub note qu'il peut renvoyer 403 ainsi que 429 pour les limites de débit ; distinguer les signaux de limite documentés du refus d'autorisation permanent plutôt que d'attribuer une signification à chaque statut.