BigQuery Python: las consultas funcionan a través del proxy, las descargas fallan
Compruebe si la descarga de resultados de BigQuery Python crea un cliente de Storage API con independencia de la ruta HTTP de la consulta.
Una consulta puede completarse correctamente y aun así fallar al descargar su resultado a pandas. La biblioteca BigQuery Python puede usar un cliente de BigQuery Storage API independiente para esa descarga.
La interfaz RowIterator.to_dataframe documenta create_bqstorage_client, que por defecto es true, y un argumento bqstorage_client. Lea esos ajustes junto con las dependencias presentes en la aplicación. El éxito en la ruta habitual de la consulta no demuestra que el transporte opcional de descarga tenga el mismo soporte ni la misma configuración de proxy.
| Etapa | Qué inspeccionar |
|---|---|
| Obtención de credenciales | El transporte de credenciales y el endpoint de identidad |
| Envío y sondeo de una consulta | La ruta de solicitud del cliente de BigQuery |
| Descarga mediante Storage API | El cliente de Storage API y su transporte |
Para una comparación controlada, la opción documentada create_bqstorage_client=False evita crear automáticamente ese cliente adicional. Eso puede ayudar a identificar qué ruta falla. Es una elección de transporte con implicaciones de rendimiento, no una prueba de que el proxy se haya reparado.
Si la aplicación proporciona su propio cliente de Storage API, configure ese cliente de forma deliberada. No suponga que un objeto HTTP personalizado adjunto a otro cliente lo reconfigurará.
Los ejemplos más antiguos hablan de implementaciones obsoletas de httplib2 o de ganchos de constructor privados. Ajuste la integración a la generación de biblioteca instalada y conserve la etapa de fallo en el informe. Un error de conversión a DataFrame y una conexión de red rechazada son resultados distintos incluso cuando ocurren en la misma llamada al método.