Le rapport Amazon est terminé, mais le connecteur échoue en ouvrant GZIP

Le rapport Amazon est marqué DONE. Son téléchargement répond correctement, mais le connecteur échoue en ouvrant GZIP. Depuis une évolution du client HTTP ou de sa configuration, l’import ne retrouve plus les lignes attendues. L’équipe cherche un changement de colonnes ; le support voit un stock qui vieillit. Le problème peut pourtant apparaître avant le premier caractère du fichier : la bibliothèque a déjà décompressé les octets que votre code tente de décompresser à nouveau.

Ce diagnostic vise un middleware qui récupère des documents avec Amazon Reports API. Le statut de traitement chez Amazon, la récupération du document et sa lecture dans votre application sont trois résultats distincts. Une réponse HTTP réussie ne prouve pas que le parseur ait reçu le bon contenu. Une erreur de lecture ne prouve pas davantage que le vendeur possède un stock vide.

Le risque est de décompresser un document déjà ouvert : chaque couche GZIP doit être ouverte une seule fois, par un responsable identifié dans le chemin de téléchargement. Nous comparons un fichier compressé livré avec un en-tête HTTP identity, le même fichier annoncé comme gzip et une lecture brute. Un exercice local reproduit les erreurs de double décompression, les octets tronqués et les caractères invalides, sans télécharger de données Amazon ni modifier une quantité.

Notre accompagnement en intégration API et reprise de connecteurs permet de retrouver cette frontière entre client HTTP, adaptateur et import métier. Le cadrage des flux API marketplace vers votre SI précise ensuite quelles données peuvent rejoindre l’ERP ou l’OMS, avec quels contrôles. L’objectif immédiat reste de lire un document déterminé, sans laisser une exception binaire décider de la disponibilité commerciale.

Pour qui : le rapport terminé ne peut plus être importé

Reconnaître une rupture après un changement de bibliothèque

Le sujet concerne les équipes e-commerce et SI dont le connecteur importe des rapports Amazon vers un traitement interne : rapprochement, suivi d’offres, inventaire ou reporting selon le type de document réellement utilisé. Le nom du rapport, le compte vendeur et la destination doivent rester dans le dossier. Tous les rapports ne décrivent ni les mêmes objets ni le même format.

Le signal faible apparaît lorsque les téléchargements continuent d’aboutir, mais que les erreurs se concentrent sur le lecteur GZIP. Une mise à jour de dépendance, un changement de méthode de lecture ou une option nouvellement transmise peut avoir déplacé la décompression. Comparez le dernier document correctement lu et le premier document rejeté avec leurs paramètres et leurs versions de client.

Identifier les incidents qui demandent une autre enquête

Un rapport encore en cours, une autorisation refusée ou un mauvais reportDocumentId ne se répare pas dans le parseur. Commencez par confirmer que vous avez obtenu le document attendu pour le bon vendeur. Si le contenu textuel s’ouvre et que seules certaines colonnes ne correspondent plus, l’enquête porte ensuite sur le contrat de ce rapport, pas nécessairement sur sa compression.

Le périmètre de l’exercice reste volontairement lisible : un fichier tabulé fictif possède deux références, des libellés accentués et deux quantités. Il permet de constater l’effet du client HTTP et de la décompression locale. Ses colonnes ne constituent pas un schéma Amazon, et ses dix unités simulées n’établissent aucune disponibilité réelle.

Anatomie du fichier : trois transformations à séparer

Relier métadonnées et contenu téléchargé

Les métadonnées JSON indiquent comment Amazon présente le document. Le transfert HTTP fournit ensuite un corps que la bibliothèque peut transformer. Enfin, l’application convertit les octets obtenus en texte et interprète les lignes. Une instruction correcte à une étape peut devenir incorrecte à la suivante si elle oublie une transformation déjà effectuée.

Le dossier de traçabilité associe donc les paramètres de getReportDocument, la valeur de compressionAlgorithm, l’en-tête Content-Encoding et la méthode qui expose le corps à l’adaptateur. Le responsable du contrat de téléchargement doit pouvoir répondre à une question simple : au moment de l’appel au lecteur GZIP, ces octets représentent-ils encore une archive ou déjà le contenu textuel décompressé ?

Ne pas confondre compression et encodage des caractères

GZIP réduit une suite d’octets ; UTF-8 définit comment des octets représentent des caractères. Ouvrir une archive ne garantit donc pas qu’un contenu textuel respecte l’encodage attendu. Inversement, changer l’encodage supposé ne répare pas une archive que l’application n’a pas ouverte. Les deux contrôles doivent rendre des erreurs différentes.

Un fichier qui affiche des symboles inhabituels peut encore être compressé, contenir un contenu textuel dans un autre encodage ou ne pas être le document recherché. Inspectez le chemin exact et les métadonnées avant d’essayer des conversions successives. Un aperçu de quelques octets aide au diagnostic ; il ne valide ni la provenance ni la complétude du rapport.

Amazon : une option peut confier GZIP au client HTTP

Vérifier le paramètre réellement transmis

Le modèle officiel Amazon Reports API consulté le 13 octobre 2026 décrit compressionAlgorithm avec la valeur GZIP. Il présente aussi enableContentEncodingUrlHeader : lorsque cette option vaut true, le document GZIP est annoncé avec Content-Encoding gzip plutôt qu’identity, afin de permettre la décompression automatique par le client HTTP.

En réalité, ces deux indications peuvent décrire la même compression. Il ne faut donc pas compter une archive pour les métadonnées et une seconde archive pour l’en-tête. Vérifiez que votre SDK et votre version exposent l’option, puis retrouvez la requête effectivement émise. La présence du paramètre dans le modèle actuel ne prouve pas qu’une ancienne bibliothèque le transmette.

Écrire deux chemins autorisés, puis choisir celui utilisé

Dans le chemin manuel, le client remet les octets compressés à l’adaptateur, qui les décompresse puis décode le contenu textuel. Dans le chemin automatique, la bibliothèque ouvre la compression annoncée par HTTP, et l’adaptateur reçoit déjà le contenu décompressé. La politique doit préciser cette différence ; elle ne peut pas se limiter à « si compressionAlgorithm vaut GZIP, ouvrir encore GZIP ».

Le statut DONE signifie que le traitement du rapport est terminé chez Amazon. La réception, la décompression, le décodage et l’import interne demandent leurs propres validations. Le document peut donc être disponible sans être intégré. N’affichez pas une synchronisation réussie au seul motif que l’API a produit ce statut.

Requests : observer les octets livrés à votre parseur

Distinguer content, iter_content et lecture brute

La documentation Requests sur la lecture des réponses distingue la réponse décodée et le flux brut. Notre test avec Requests 2.33.1 confirme que content et iter_content rendent le contenu textuel lorsqu’un même corps GZIP est annoncé avec Content-Encoding gzip. Avec identity, content conserve les octets compressés de cette fixture.

Une lecture raw, avec stream activé et le décodage de contenu explicitement désactivé dans notre test, conserve l’archive. Le choix de cette méthode change la responsabilité de l’adaptateur. L’en-tête gzip reste pourtant visible après la lecture automatique : le relire ne démontre pas qu’il reste une archive à ouvrir.

Consigner le contrat de la méthode de téléchargement

Faites remonter un état explicite depuis le chemin HTTP choisi : octets bruts à ouvrir, ou contenu déjà décompressé. Cet état doit venir d’un comportement contrôlé de la bibliothèque, vérifié en recette. Il ne doit pas être une case choisie par le support pour faire passer un fichier qui échoue. Les paramètres de lecture et la version de dépendance font partie de la preuve.

Si vous changez de client, de SDK ou de méthode de streaming, rejouez la même fixture avant le déploiement. La recette compare le corps remis au parseur, pas seulement le code de retour HTTP ou la cadence de polling. Elle doit constater que les accents, le nombre de lignes et les valeurs fictives survivent au nouveau chemin de lecture.

Exercice corrigé : neuf situations de lecture du rapport

Prédire la sortie avant de consulter la correction

Un serveur HTTP local fournit le même petit fichier sous plusieurs conditions. Le cas concret A livre une archive avec identity ; B livre cette archive avec gzip ; C la remet par le flux brut. Pour chacun, notez si l’adaptateur doit encore ouvrir GZIP, puis indiquez à quel moment le parseur peut lire les références. Une réponse « ouvrir systématiquement parce que les métadonnées disent GZIP » doit échouer en B.

Les autres situations provoquent une mauvaise étape ou un fichier refusé. Le lecteur doit distinguer un échec de décompression, une conversion de caractères impossible et un document tabulé réellement sans ligne de données. Les décisions ci-dessous concernent cette fixture ; le contrat d’un rapport Amazon donné reste à vérifier séparément.

Lire ce que les vingt-six contrôles établissent

Les vingt-six assertions passent sur Python 3.14.7 et Requests 2.33.1. Elles vérifient les chemins HTTP réels de la fixture, la conservation des accents, les deux lignes, les quantités et plusieurs refus. Un en-tête gzip associé à un corps non compressé provoque aussi une erreur du client ; une réponse 403 est rejetée avant toute lecture métier. Ces variantes évitent de limiter le diagnostic au seul cas nominal. Une panne de téléchargement ou un timeout, en revanche, relève d’une tentative réseau distincte ; il ne faut pas les ranger parmi les erreurs de caractères.

Le plafond testé protège la sortie de la décompression manuelle de cet exercice. L’utilisation de content sur ces petits fichiers ne constitue pas une implémentation de téléchargement borné en production. La recette ne teste ni appels Amazon, ni permissions vendeur, ni taille réelle d’un rapport, ni écriture ERP. Elle démontre la transformation des octets, pas la validité commerciale de l’import.

Refuser un fichier illisible sans déclarer le stock à zéro

Conserver trois résultats de lecture distincts

Un document illisible, un contenu textuel lisible sans ligne et un fichier dont certaines lignes sont refusées ne doivent pas partager le même résultat interne. L’exemple H retourne zéro ligne parce que son en-tête fictif est valide et qu’aucune donnée ne suit. E et F échouent avant cette conclusion. Les transformer tous en liste vide ferait disparaître la cause.

Pour un rapport consommé par un suivi de stock, l’absence de lignes doit encore recevoir sa signification métier. Selon le type de rapport, son périmètre et son contrat, elle peut justifier une enquête plutôt qu’une remise à zéro. Le parseur ne choisit pas cette règle. L’ERP, l’OMS ou le consommateur conserve l’état confirmé avec sa date et expose l’échec du nouvel import.

Arrêter l’application des valeurs au bon endroit

Le seuil de publication doit précéder toute écriture issue du document. Si la décompression ou le décodage échoue, alors le document rejoint une quarantaine et aucune quantité n’est tirée de cette tentative. Si le contenu textuel est lisible mais son schéma de colonnes ne correspond pas au rapport attendu, bloquez à l’étape de contrat. Si seul un lot de lignes échoue, appliquez la politique de traitement partiel explicitement prévue, avec la liste des lignes retenues et rejetées. Le mapping métier ne reçoit que les entrées admises par ce contrat.

Le maintien de la dernière donnée connue ne garantit pas qu’elle reste vendable indéfiniment. Son âge doit alimenter le seuil existant de fraîcheur et de risque commercial, avec son repli autorisé. L’incident GZIP fournit une cause au défaut de rafraîchissement ; il ne remplace pas le calcul de disponibilité FBA ni les arbitrages du canal.

Prévoir le budget de lecture des rapports volumineux

Le volume impose deux budgets différents : octets reçus et octets après décompression. Un fichier compact peut produire une sortie beaucoup plus grande. Fixez les limites à partir du rapport utilisé, de ses volumes et de la mémoire du worker ; le plafond de 4 096 octets du laboratoire est uniquement un témoin de refus. Il ne dimensionne pas votre collecteur Amazon.

Une implémentation de streaming doit contrôler les deux étapes selon le comportement de la bibliothèque retenue. Le monitoring distingue dépassement de taille, délai réseau et durée de parsing, avec un arrêt propre et une sortie non publiée. Notre fixture teste un plafond manuel sur un petit fichier ; les flux automatiques et les vrais volumes exigent leur recette dédiée avant de transférer cette règle en production.

Reprendre le document avec une provenance vérifiable

Garder une preuve sans exposer le lien de téléchargement

Le runbook de reprise et sa journalisation conservent vendeur, identifiant du rapport, reportDocumentId, type de rapport, tentative, paramètres, dépendances et version du chemin de lecture. Il sépare l’empreinte des octets téléchargés de celle du contenu après transformation, en précisant à quelle étape chaque empreinte est calculée. Un fichier brut et son texte ont légitimement des empreintes différentes.

Le support a besoin du motif et de la prochaine action, pas d’une copie publique des données ni d’un lien présigné dans un ticket largement accessible. Conservez le document selon les droits et la durée prévus pour son contenu. L’empreinte facilite la comparaison des tentatives ; elle ne constitue pas à elle seule une preuve d’origine Amazon ou d’exhaustivité.

Rejouer la lecture avant de rouvrir le consommateur

La première reprise du cas concret B se fait sur une copie contrôlée, avec les mêmes métadonnées et la méthode HTTP identifiée. L’adaptateur corrigé doit produire le contenu textuel attendu sans seconde décompression. Comparez les lignes avec le dernier import confirmé ou un témoin validé pour le rapport concerné, sans confondre l’exemple tabulé du laboratoire avec ce contrat réel.

Une lecture retrouvée n’autorise pas automatiquement le rejeu des effets. Le journal doit montrer si une tentative antérieure a déjà appliqué des lignes. L’idempotence de l’import ou son mécanisme de remplacement doit empêcher une double application, selon la destination. Ce contrôle est requis pour la reprise métier ; il n’est pas démontré par notre laboratoire de téléchargement.

Plan d’action : réparer un seul chemin de lecture

Faire constater l’écart avant de changer toutes les archives

D’abord, sélectionnez un document refusé et relevez la première exception, sa méthode de lecture et les paramètres de récupération. Ensuite, faites comparer par le développeur les octets remis à l’adaptateur dans le dernier chemin sain et dans le nouveau. Le responsable du flux confirme la destination concernée et les imports encore autorisés. Le support rattache les tickets à ce périmètre pour éviter un diagnostic global « Amazon indisponible ».

Le correctif doit porter sur un chemin identifié, avec un rollback vers le dernier chemin confirmé, avec un test qui échoue avant sa modification et réussit après. À différer : les nettoyages de colonnes et changements de stock qui n’expliquent pas l’exception. À refuser : une conversion permissive ou une capture d’erreur qui transforme le fichier en tableau vide. Ces gestes peuvent masquer l’incident au lieu de retrouver le document.

• À faire d’abord : isoler le document refusé avec les paramètres et la méthode qui ont fourni ses octets.
• À valider ensuite : attribuer une seule décompression à ce chemin avant le parseur.
• À refuser : déclarer un import réussi ou une quantité nulle après une erreur de lecture.
• À différer : reprendre les écritures tant que le contrat du rapport et les effets antérieurs ne sont pas rapprochés.

Décider la réouverture sur le document et ses consommateurs

En priorité, rejouez les lectures identity, automatique et brute si votre connecteur les autorise. Testez ensuite archive tronquée, mauvais encodage, algorithme inconnu et dépassement du budget défini pour vos vrais volumes. Le passage en production demande un contenu textuel correctement lu, un contrat de rapport validé et une liste claire des destinations encore bloquées. Un seul compteur HTTP vert ne suffit pas.

Lors de la réouverture, mesurez les documents téléchargés, lisibles, refusés au format et effectivement consommés. Vérifiez l’âge des dernières données appliquées et les reprises encore en attente. Si le nouvel adaptateur relit le contenu textuel mais que la destination reçoit deux fois une même application, alors l’import reste fermé : la réparation GZIP est acquise, mais la reprise métier ne l’est pas.

Erreurs fréquentes : compter deux décompressions pour un même fichier

Décompresser jusqu’à ce que quelque chose ressemble à du texte

Une boucle qui ouvre toute signature GZIP rencontrée donne l’impression de gérer les variantes. Elle supprime pourtant le contrat : l’adaptateur ne sait plus combien de transformations étaient attendues, ni si les octets appartiennent au document reçu. Dans le cas Amazon décrit ici, les métadonnées et l’en-tête peuvent viser une seule couche. Une éventuelle archive imbriquée demande une autre justification explicite.

La bonne erreur mentionne l’étape qui échoue et l’état attendu des octets. Elle préserve le document pour l’enquête dans un stockage contrôlé. Elle ne continue pas vers un parseur alternatif uniquement parce que le premier a refusé le contenu. Une apparence lisible reste insuffisante pour autoriser un import.

Prendre le contenu déjà transformé pour le flux brut

Enregistrer content sous un nom de fichier terminé par .gz ne recrée pas une archive. Si la bibliothèque a décompressé HTTP, ce fichier peut déjà contenir le contenu textuel. Son extension et la valeur Content-Length du transfert ne décrivent pas nécessairement les octets sauvegardés par l’application. Le dossier doit conserver le stade exact de la copie.

La recette peut contrôler taille et empreinte avant et après transformation sur une fixture connue. Pour un vrai rapport, ces mesures aident à retrouver une divergence ; elles ne remplacent pas le contrôle de format ni le rapprochement des objets. Évitez de promettre une preuve d’intégrité métier à partir de la seule taille du téléchargement.

Guides complémentaires : replacer le document dans les flux Amazon

Le lecteur GZIP se situe au début de la chaîne d’import. Une fois ce passage réparé, les ressources suivantes aident à distinguer la cadence Amazon, le sens du stock et les validations qui doivent encore précéder les effets dans le SI.

Réserver la capacité aux opérations Amazon utiles

Le diagnostic Amazon SP-API : quotas et commandes traite la priorité des files et la reprise des flux. Il aide à replacer les documents refusés dans une collecte maîtrisée, sans multiplier les requêtes alors que la panne se situe dans la lecture locale.

La récupération peut attendre une place dans la file sans être défectueuse. Ce diagnostic aide à séparer ce retard normal d’un fichier déjà reçu mais refusé par l’adaptateur. Augmenter le débit ne corrige pas une seconde ouverture de GZIP.

Interpréter le stock et les opérations de fulfillment

Le diagnostic Amazon FBA : stocks, MCF et statuts distingue les familles SP-API et leurs décisions. Il complète la lecture technique du fichier lorsque son consommateur doit expliquer une quantité, sans transformer toute donnée issue de Reports en disponibilité immédiatement vendable.

Les états du réseau fulfillment gardent leur définition et leur provenance. Une réparation du téléchargement ne les rend pas interchangeables avec une quantité ERP. Le responsable du stock doit encore confirmer quelle entrée alimente quelle décision.

Rattacher les rapports au contrat du connecteur

La lecture API marketplace : catalogue, offres et webhooks replace les traitements asynchrones dans le parcours vendeur et SI. Le document lisible y devient une entrée dont les lignes doivent encore être rapprochées avec les objets et les responsabilités du flux.

Cette perspective devient utile si le même import prépare une mise à jour locale puis une action dans un autre système. La reprise conserve ces étapes séparées pour ne pas confondre document relu et effet déjà appliqué.

Conclusion : savoir qui a déjà ouvert le rapport

Arrêter le diagnostic à la bonne frontière

Un rapport Amazon terminé peut rester inutilisable dans votre connecteur. Le point décisif est le contenu livré à l’adaptateur : archive encore compressée ou texte déjà ouvert par le client HTTP. Le même GZIP annoncé par les métadonnées et par l’en-tête ne réclame pas deux ouvertures successives.

La lecture correcte doit ensuite franchir ses autres contrôles : caractères, format, lignes et consommateurs. Le refus d’une archive tronquée ne signifie pas stock nul. Une fixture qui passe ne valide pas un rapport Amazon réel. Ces distinctions donnent au support une cause exploitable et au responsable du flux une condition de réouverture.

Faire reprendre le téléchargement avec sa destination

Le cadrage de vos connecteurs API marketplace peut partir d’un document refusé, de ses paramètres et du dernier import confirmé. Il relie la méthode de lecture aux contrôles de reprise attendus par les équipes qui consomment ses données.

Dawap peut vous accompagner en intégration API sur mesure pour reproduire l’erreur de téléchargement, corriger la frontière de décompression et préparer une recette de réouverture. Votre SI retrouve ainsi un document interprétable et un import dont les effets sont vérifiés avant de reprendre l’exploitation.