Deux fichiers nommés BL-4182-r1.pdf apparaissent dans Google Drive après la reprise du connecteur. Le premier envoi avait terminé sur un timeout ; le second paraît réussi. L’ADV ne sait plus quel lien transmettre au commercial, et le dossier de livraison conserve une référence différente de celle partagée au client. Effacer la copie la plus récente peut même retirer le document déjà utilisé. Le problème commence avant le nettoyage : quelle identité le connecteur a-t-il demandée à chaque création ?
Le diagnostic doit commencer par l’identifiant conservé pour cette révision. Une session de transfert permet de poursuivre l’envoi des octets, mais elle ne remplace pas l’identité du fichier à créer. Pour un PDF binaire, un identifiant préparé par l’API puis conservé pour la même révision documentaire évite de changer de cible à chaque tentative incertaine. Il faut ensuite distinguer une réponse de transfert, une ressource retrouvée et son association au bon de livraison. Le nom du PDF ne suffit à fermer aucune de ces étapes.
Notre exercice original a passé 63 contrôles avec le SDK Google 2.201.0 sous Python 3.14.8. Il suit 24 échanges préparés, sans connexion à Drive, et examine les requêtes réellement produites par le client. Les réponses et les octets sont fictifs : aucun compte, fichier distant ou rattachement ERP n’est testé. Vous verrez comment conserver l’identifiant demandé, reprendre au décalage acquitté et laisser un conflit 409 visible plutôt que le convertir en réussite métier.
Le raccordement de Google Workspace aux documents de votre SI doit prendre en charge cette continuité. Une intégration API des pièces de livraison relie la révision générée dans la gestion commerciale, les octets envoyés et la référence conservée pour les utilisateurs. Le connecteur peut alors reprendre un dépôt incertain sans demander à l’ADV de choisir manuellement entre deux fichiers homonymes.
Dans quel cas : deux copies du même bon de livraison
Reconstituer les deux créations plutôt que comparer seulement les noms
Le scénario fictif part d’un ERP qui produit la révision r1 du bon de livraison BL-4182. Un traitement doit déposer son PDF dans un dossier Drive déterminé, puis conserver le lien utile au service commercial. Après une réponse perdue, le traitement reprend la tâche avec le même nom et un nouvel identifiant de fichier. Ce changement peut ouvrir une seconde création. Il ne représente pas simplement une autre tentative technique sur la première ressource.
Pour examiner un incident réel, rapprochez la référence du bon, sa révision, le compte Google utilisé et les identifiants demandés ou obtenus lors des tentatives. Notez séparément les sessions de transfert et leurs résultats connus. La description de la ressource File précise que le nom n’est pas nécessairement unique dans un dossier. Une recherche sur ce nom peut donc retrouver plusieurs candidats sans désigner celui que votre application devait créer.
Reconnaître les situations qui demandent un autre diagnostic
Deux révisions décidées par le métier ne sont pas automatiquement un doublon à supprimer. Un bon corrigé après modification des quantités peut devoir rester distinct du document précédemment diffusé. À l’inverse, deux identifiants Drive pour la même révision inchangée peuvent révéler une reprise mal conçue. Le responsable ADV doit établir cette différence avant que le développeur choisisse entre nouvelle création, mise à jour ou simple restitution d’un fichier déjà présent.
Ce dossier concerne le dépôt d’un fichier binaire, sans conversion en document Google natif. Il ne traite pas la génération correcte du PDF, la signature du document ou sa valeur d’archivage. Si les octets sont déjà différents avant l’appel Drive, un mécanisme de reprise ne répare pas leur provenance. Le coût à mesurer est concret : recherches de la bonne copie, liens divergents dans les outils et dossiers dont personne ne peut expliquer la version transmise.
Réserver l’identité du fichier avant le premier envoi
Obtenir un identifiant utilisable pour la création
La méthode files.generateIds fournit des identifiants utilisables dans des requêtes de création ou de copie. Le laboratoire construit une demande explicite d’un identifiant de type fichier dans l’espace Drive. Le SDK reçoit ensuite une réponse préparée contenant une valeur fictive. Cette lecture locale éprouve la construction et le décodage du client ; elle n’a réservé aucun identifiant auprès de Google.
Le connecteur réel doit conserver la correspondance avant la première création : entreprise concernée, bon BL-4182, révision r1 et identifiant réservé. La taille et l’empreinte de la source attendue aident à reconnaître les octets à reprendre. Cette conservation doit survivre au remplacement du worker. Si chaque relance consulte de nouveau le générateur d’identifiants sans retrouver l’affectation précédente, l’application recommence précisément le choix qui devait rester stable pour ce document.
Conserver une affectation documentaire, pas une nouvelle identité par tentative
La méthode files.create reçoit les métadonnées du fichier. Voici les quatre champs fictifs réellement sérialisés par le SDK dans notre essai de dépôt. Leur présentation est remise en forme pour la lecture. L’identifiant et le dossier sont des valeurs de laboratoire ; en exploitation, ils doivent provenir des références autorisées du flux, et non être recopiés depuis cet exemple.
{
"id": "identifiant-reserve-fictif-A",
"name": "BL-4182-r1.pdf",
"mimeType": "application/pdf",
"parents": ["dossier-fictif-ADV"]
}Le contre-exemple construit une seconde demande avec le même nom, mais un identifiant fictif B. Le programme constate cette différence dans le corps sérialisé sans envoyer cette demande. Il ne prétend donc pas avoir créé deux fichiers pour prouver le risque. La règle native de reprise avec identifiant préparé est décrite par Google ; l’expérience montre, elle, quelle identité le code remet réellement au client lors de chaque construction.
Reprendre les octets sans recréer le document
Séparer le début d’une session du résultat de création
La documentation des transferts reprenables distingue la réponse initiale 200, son en-tête Location et le retour final de la ressource. L’ouverture de session a un corps vide. Son URI sert au transfert et à son suivi ; elle n’est pas l’identifiant durable à rattacher au bon. Dans le laboratoire, le premier appel à next_chunk() ouvre cette session puis tente déjà un premier envoi de données.
L’application doit donc conserver deux informations différentes : le fichier visé par la révision et l’état de son transfert en cours. Le monitoring peut afficher le bon, l’identifiant prévu, la quantité acquittée et la dernière étape observée, sans exposer l’URI de session complète dans les journaux ordinaires. Une nouvelle session ne justifie pas, à elle seule, une autre identité documentaire ; sa conservation et son accès demandent également une politique adaptée aux documents transportés.
Relire la quantité reçue après une réponse incertaine
Une sonde vide permet d’interroger une session incertaine. Selon Google, 200 ou 201 indique un transfert terminé ; 308 demande d’examiner Range. Sans cet en-tête, aucun octet n’est confirmé. Un 404 de session appelle un redémarrage du transfert. Ces réponses concernent cette opération : elles n’autorisent pas à renommer tout refus d’accès ou tout conflit de création « session expirée ».
Le témoin contient 786 432 octets synthétiques et demande des blocs de 524 288 octets. Après le premier bloc tenté, la réponse préparée n’acquitte que 262 144 octets. Le SDK poursuit alors au décalage 262144, compté depuis zéro, avec la tranche correspondante de la source. Il n’utilise pas 524288 comme prochain départ parce que cette quantité avait été présentée au transport. Cette observation distingue l’envoi tenté de l’avancement effectivement annoncé par la réponse fournie.
Exercice corrigé : suivre 24 échanges du SDK hors connexion
Exécuter le client avec des réponses explicitement préparées
Le programme d’examen des reprises Drive emploie le client officiel Google 2.201.0, publié le 30 septembre 2026, et son document Drive embarqué, révision 20260916. Il vérifie cette version et l’empreinte du document de découverte. La séquence de données reste en mémoire ; son type déclaré est PDF, mais son contenu n’est pas un PDF validé. Aucune pièce commerciale réelle n’est ouverte.
python3 -m venv .venv-drive
.venv-drive/bin/python -m pip install google-api-python-client==2.201.0
.venv-drive/bin/python -B resumable_file_identity_inventory.py
# checks_passed: 63
# prepared_transport_invocations: 24
# real_http_requests: 0
# connection_attempts: 0Ces commandes préparent un environnement local de type Unix ; l’installation des dépendances est distincte de l’essai hors connexion. Le programme fournit au SDK un transport qui consomme une liste de réponses préparées et n’envoie rien. Le seuil de cet essai est zéro appel au client HTTP réel et zéro tentative de connexion instrumentée ; les gardes font échouer le programme si une tentative survient. Les 24 appels observés sont ceux de ce transport fictif. La lecture des traces distingue les données tentées de la sonde vide qui suit un résultat incertain.
Le code du client dans cette version permet de rapprocher les traces des transitions exercées. Nous appelons réellement next_chunk() et la lecture de métadonnées avec ce transport, au lieu de réécrire un moteur qui déciderait lui-même des reprises attendues. Le paramètre de retry reste à zéro dans les appels de l’expérience ; les nouvelles tentatives prévues par chaque scénario sont explicites et observables.
Lire les écarts entre tentative, acquittement et résultat fourni
Le tableau présente six points de contrôle. Dans le cas de réponse finale perdue, le premier bloc est acquitté, puis le transport lit les 262 144 derniers octets et lève le timeout préparé. Cela ne dit pas ce qu’un serveur aurait reçu. L’appel suivant du SDK sonde la session. Si la réponse préparée annonce la fin et fournit une ressource, le client la décode sans nouvel envoi de données. Le fichier distant reste fictif, même si ce chemin du SDK est réellement exécuté.
| Observation préparée | Résultat observé |
|---|---|
| Envoi partiellement reçu | Reprise au décalage 262144 |
| Réponse finale perdue | Sonde puis ressource fournie |
| Sonde 308 sans Range | Nouvel envoi depuis zéro |
| Session en 404 | Exception sans nouvel identifiant |
| Création en 409 | Exception, lecture distincte ensuite |
| Nom identique, autre ID | Autre identité demandée |
Un autre cas fournit 308 à la sonde, avec un avancement partiel. Paradoxalement, le même appel à next_chunk() sonde la session puis envoie le bloc suivant avant de rendre son résultat. Compter les appels de méthode ne permet donc pas de compter les échanges avec le transport. L’essai sans Range vérifie une reprise depuis zéro, puis une continuation après un nouvel acquittement. La tranche de source effectivement lue est comparée à celle attendue, pas seulement à sa longueur.
Après un 409, retrouver la ressource réellement concernée
Garder le conflit de création visible
Google documente la reprise d’un envoi avec un identifiant préparé après un résultat indéterminé. Si l’action a réussi, une nouvelle tentative retourne 409 sans créer un doublon. Cette possibilité ne couvre pas la création ordinaire des documents Google Workspace ni leur conversion, avec les exceptions précisées par Google. Notre cas reste un PDF binaire ; il ne transpose pas la règle à une feuille Google native.
Dans l’exercice, une réponse 409 préparée lors de l’ouverture de session produit une exception ResumableUploadError. Le client n’ouvre pas de session et n’envoie pas les données. Le programme constate aussi que le corps de cette tentative conserve l’identifiant A. Il n’annonce pas « bon de livraison déposé » sur ce seul statut. Une lecture distincte demande ensuite les métadonnées du fichier réservé ; elle n’est pas un acquittement ERP dissimulé dans le traitement de l’erreur.
Examiner le fichier attendu et conserver les inconnues
Le client construit files.get pour cet identifiant et demande explicitement nom, type, parents, taille et empreinte MD5 avec l’ID. Dans le témoin, size reste une chaîne JSON et md5Checksum concerne le contenu binaire. La comparaison locale porte sur cinq champs fournis : identité, type, destination, taille et empreinte. Le nom reste informatif. Deux réponses supplémentaires préparées signalent respectivement un autre dossier parent et une empreinte absente.
Une taille identique n’authentifie pas le document ; une empreinte MD5 n’est ni une signature ni un contrôle d’innocuité. Même cinq champs concordants ne prouvent pas les permissions attendues ou le rattachement dans votre application. Le scénario laisse ces confirmations à la recette réelle. Si les métadonnées restent indisponibles avec le compte prévu, le support conserve un dépôt à examiner, plutôt que fabriquer un nouvel identifiant pour faire disparaître le conflit et obtenir enfin une réponse verte.
Éviter les reprises qui fabriquent une autre version
Figer les octets et l’affectation du bon de livraison
La même identité Drive ne rend pas interchangeables deux contenus. Si le PDF est régénéré entre les blocs avec d’autres quantités, reprendre son transfert comme si la source était inchangée devient une autre erreur. Le dossier de reprise doit retrouver les octets de r1, leur taille et leur référence de confiance. Une nouvelle révision décidée par le métier demande son propre traitement ; elle ne doit pas hériter silencieusement de l’envoi partiel du document précédent.
Notre laboratoire utilise une source constante et compare ses tranches ; il ne redémarre pas un vrai worker et n’éprouve pas de concurrence entre processus. La base qui conserve l’affectation, les règles d’exclusion entre workers et la récupération après crash doivent être testées dans l’architecture choisie. Ajouter un identifiant au corps JSON ne résout pas une course où deux workers ont déjà réservé chacun une valeur pour BL-4182 r1. L’idempotence du flux dépend aussi de cette affectation commune.
Le diagnostic de la pièce jointe absente du worker n8n complète ce point : un traitement peut posséder une référence sans pouvoir relire les octets attendus. La récupération d’une pièce privée Zendesk traite encore une autre frontière, celle de l’acquisition autorisée. Ni la disponibilité locale ni le téléchargement source ne remplacent le suivi de création Drive montré ici.
Ne pas confondre droit absent, session perdue et nouvelle création
Les identifiants préparés sont documentés dans le contexte de l’utilisateur demandeur. Conservez le contexte d’accès avec le travail à reprendre et qualifiez une éventuelle relève de compte. Le programme ne teste ni OAuth ni les permissions du dossier. Déclarer une capacité de gestion des Drives partagés, lorsque l’intégration en a besoin, ne constitue pas à elle seule un droit d’écriture. Ces conditions doivent être vérifiées sur l’environnement réel avant que les documents de livraison y circulent.
Le backoff peut espacer des tentatives lors d’une indisponibilité, mais il ne choisit pas l’identité du document. Le runbook doit distinguer l’échec de création, le suivi d’une session et une lecture de réconciliation. Dans le cas 404 préparé, le SDK expose une erreur sans réserver un autre fichier. Le redémarrage du transfert relève ensuite du connecteur et garde l’affectation documentaire attendue. Un rollback doit préserver cette correspondance et les dépôts incertains, plutôt que réinitialiser la file comme une série de documents neufs.
Plan d’action : reprendre le dépôt d’un bon de livraison témoin
Choisir une révision dont les équipes connaissent le contenu
Le responsable ADV choisit un bon synthétique ou une pièce autorisée pour la recette et confirme sa révision. Le responsable du connecteur relève le client installé et le fonctionnement de sa file. L’administrateur Workspace qualifie le compte, le dossier et les accès attendus. L’intégrateur ERP intervient sur la génération de la pièce et sur la conservation de la référence dans la gestion commerciale lorsque ces interfaces relèvent de son périmètre. Dawap peut coordonner ces passages sans se substituer à leur validation métier.
- Identifier le bon, sa révision et les octets qui doivent rester disponibles pendant la reprise.
- Retrouver l’affectation durable à l’identifiant Drive avant toute nouvelle création.
- Observer séparément la requête de création, la session et la quantité réellement acquittée.
- Provoquer en recette une réponse perdue, une reprise partielle et un conflit sur le même identifiant.
- Relire la ressource prévue, vérifier sa destination et confirmer le lien conservé côté gestion.
- Faire reprendre un dossier incertain après remplacement du worker, sans réserver une seconde identité.
Le seuil de notre témoin est précis : r1 conserve son affectation à A, les octets repris correspondent à la source convenue et aucun état inconnu n’est présenté comme un dépôt confirmé. Les 63 contrôles locaux vérifient leurs observations préparées ; la recette connectée doit encore confirmer la ressource, les accès et le lien côté gestion. Le test après remplacement de processus est indispensable pour démontrer la persistance que notre programme en mémoire ne couvre pas.
Traiter les doublons existants sans effacer les liens utiles
Avant tout nettoyage réel, inventoriez les identifiants des fichiers homonymes et les applications qui les référencent. L’ADV peut avoir transmis un lien, tandis que l’ERP en conserve un autre. Décider quelle copie garder exige d’examiner révision, contenu, emplacement et usages autorisés. La correction du connecteur n’est pas une autorisation de supprimer les anciens fichiers. Une remise en cohérence des liens doit avoir son propre suivi afin de ne pas réparer le prochain dépôt au prix d’un document déjà diffusé devenu inaccessible.
La journalisation utile suit BL-4182 r1, son identifiant affecté, la phase en cours, les octets acquittés et la dernière lecture connue. La latence de transfert et l’ancienneté des dépôts incertains servent à repérer les attentes ; le nombre de tentatives ne mesure pas le nombre de documents livrés. Le contrat de sortie conserve l’identifiant Drive affecté, la révision du bon et un état de dépôt explicite. Le mapping de retour vers la gestion préserve ces données, sans remplacer l’identité du fichier par l’URI d’une session terminée ou par le seul nom visible dans le dossier.
Conclusion : le bon de livraison conserve son fichier et sa révision
Un timeout de transfert ne doit pas transformer BL-4182 r1 en nouvelle demande de document. Le diagnostic rapproche l’identifiant réservé, la session et les octets acquittés, puis traite le conflit de création sans le masquer. L’expérience montre ces transitions du SDK sur 24 échanges préparés ; elle ne prouve pas qu’un fichier existe dans votre Drive. Cette limite laisse à la recette connectée les contrôles qu’elle seule peut établir.
Notre prestation d’intégration Google Workspace pour vos échanges documentaires peut commencer par ce dépôt témoin. Nous examinons avec vos équipes la conservation des références, la reprise du client et le retour vers la gestion commerciale. Le service ADV doit retrouver un lien explicable pour une révision donnée, et une attente visible lorsque le transfert ou son rattachement reste à confirmer.
Si vos bons de livraison se multiplient après chaque relance, Dawap peut cadrer et développer le middleware API entre votre ERP et vos documents partagés avec votre intégrateur de gestion. Le premier livrable sera une reprise vérifiable sur une pièce connue : une affectation conservée, les bons octets remis au client et une référence de retour contrôlée dans l’outil utilisé par vos équipes.
