BigQuery Python : les requêtes passent par le proxy, les téléchargements échouent
Vérifiez si le téléchargement des résultats de BigQuery Python crée un client Storage API indépendamment du chemin HTTP de la requête.
Une requête peut se terminer correctement et échouer néanmoins lors du téléchargement de son résultat dans pandas. La bibliothèque BigQuery Python peut utiliser un client BigQuery Storage API distinct pour ce téléchargement.
L'interface RowIterator.to_dataframe documente create_bqstorage_client, qui vaut true par défaut, ainsi qu'un argument bqstorage_client. Lisez ces réglages avec les dépendances présentes dans l'application. Un succès sur le chemin de requête ordinaire ne prouve pas que le transport de téléchargement optionnel dispose du même support ni de la même configuration de proxy.
| Étape | Ce qu'il faut examiner |
|---|---|
| Obtention des identifiants | Le transport des identifiants et le point de terminaison d'identité |
| Soumission et interrogation d'une requête | Le chemin de requête du client BigQuery |
| Téléchargement via Storage API | Le client Storage API et son transport |
Pour une comparaison contrôlée, l'option documentée create_bqstorage_client=False évite de créer automatiquement ce client supplémentaire. Cela peut aider à identifier le chemin qui échoue. C'est un choix de transport ayant des conséquences sur les performances, et non la preuve que le proxy lui-même a été réparé.
Si l'application fournit son propre client Storage API, configurez ce client délibérément. Ne supposez pas qu'un objet HTTP personnalisé attaché à un autre client le reconfigure.
Les exemples plus anciens évoquent des implémentations httplib2 obsolètes ou des crochets de constructeur privés. Alignez l'intégration sur la génération de bibliothèque installée et conservez l'étape d'échec dans le rapport. Une erreur de conversion DataFrame et une connexion réseau refusée sont des issues différentes, même lorsqu'elles surviennent dans le même appel de méthode.