Olá, estou recebendo erro ao criar uma destination BigQuery utilizando GCS staging bucket, a UI retorna timeout (504 / upstream request timeout) durante o check da connection.

Pelos conhecimentos disponíveis, esse tipo de erro 504 / “upstream request timeout” durante o check ou discover schema normalmente não é um problema específico do conector BigQuery + GCS, e sim de timeout no ingress / load balancer que fica na frente do Airbyte. Alguns pontos relevantes: • A documentação recomenda explicitamente aumentar os timeouts do ingress para evitar 504 ao criar fontes/destinos, pois operações de check e schema discovery podem demorar mais de 60s. [Implementation guide] • Em um caso semelhante, o discover schema falhava com 504 e a solução foi aumentar o timeout do NGINX / load balancer, pois o conector ainda estava rodando em background. [Forum 2665; Github 71797] • Outro usuário em Kubernetes resolveu 504 ajustando as anotações do Ingress NGINX, por exemplonginx.ingress.kubernetes.io/proxy read timeout '600' nginx.ingress.kubernetes.io/proxy-send-timeout: '600'[Github 71797] • Há também relatos de 502/504 em criação de conexão onde a recomendação foi “aumentar o timeout do servidor / LB”, pois o check leva mais tempo que o limite padrão. [Forum 1207; Forum 594; Github 58627] Com base nisso, os passos sugeridos são: 1. Verificar onde está o timeout ◦ Se estiver atrás de NGINX Ingress (Kubernetes), ajuste

proxy-read-timeout

e

proxy-send-timeout

para um valor maior (ex.: 300–600s). [Implementation guide; Github 71797] ◦ Se houver outro load balancer / proxy (oauth proxy, API gateway, etc.), verifique o timeout de upstream dele. [Github 58627] 1. Testar o mesmo check sem passar pelo LB ◦ Se possível, acesse o

airbyte-server

diretamente (porta interna) e repita o _check connection_; se funcionar sem 504, confirma que o problema é de timeout no caminho (LB/Ingress) e não no conector em si. [Forum 1207] 1. Verificar se o conector realmente termina ◦ Mesmo com 504 na UI, veja nos logs do job de check (worker) se ele conclui com sucesso ou erro; isso ajuda a diferenciar entre “apenas timeout de UI” e falha real no BigQuery/GCS. 1. Checar versão do destino BigQuery ◦ Há correções recentes relacionadas a GCS staging (por exemplo, melhor tratamento de erros de bucket ausente/inacessível na versão 3.0.20). Se estiver em uma versão bem antiga, pode valer atualizar o conector BigQuery. [BigQuery GCS fix] Se você puder informar: • Como o Airbyte está implantado (Docker, Kubernetes, Helm, etc.) • Se há NGINX / outro LB na frente • A versão do destino BigQuery posso tentar apontar exatamente onde ajustar o timeout com base nesses exemplos. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai estou com outro erro aatualmente: 2026-06-24 121841,759 [io-executor-thread-1] ERROR i.a.c.s.e.h.KnownExceptionHandler(handle):34 - Known Exception: class KnownExceptionInfo { │ │ message: Failed to access database. Check the server logs for more information │ │ exceptionClassName: io.airbyte.commons.server.errors.ConflictException │ │ exceptionStack: [io.airbyte.commons.server.errors.ConflictException: Failed to access database. Check the server logs for more information, at io.airbyte.server.apis.ApiHelper.ex │ │ rootCauseExceptionClassName: null │ │ rootCauseExceptionStack: [] │ │ details: null │ │ }

O erro

Failed to access database. Check the server logs for more information

com

ConflictException

é exatamente o mesmo padrão documentado em issues conhecidos do Airbyte. [Github Issue] O que esse erro indica O

airbyte-server

está conseguindo iniciar, mas falha ao executar queries no banco de dados PostgreSQL. Isso pode ocorrer por: 1. Incompatibilidade de schema do banco após upgrade/downgrade de versão (migrations do Flyway em estado inconsistente) 2. Banco de dados inacessível ou com problemas de conectividade intermitente 3. Versão do PostgreSQL incompatível com a versão do jOOQ usada pelo Airbyte Passos para investigar 1. Verifique os logs do pod `airbyte-db`:

kubectl logs -n airbyte <airbyte-db-pod-name>

Procure por erros de startup, corrupção de dados ou problemas de permissão. [Github Issue] 2. Verifique a versão de migração do banco: Nos logs do

airbyte-server

, procure por linhas como:

Current database migration version X.X.X.XXX

Se a versão de migração estiver desatualizada em relação à versão do Airbyte em execução, pode haver incompatibilidade. [Github Issue] 3. Verifique o pod do bootloader:

kubectl get pods -n airbyte | grep bootloader
kubectl logs -n airbyte <airbyte-bootloader-pod>

O bootloader é responsável por aplicar as migrations; se ele falhou, o banco pode estar em estado inconsistente. [Github Issue] 4. Verifique conectividade com o banco:

kubectl get endpoints airbyte-db-svc -n airbyte

Solução relatada pela comunidade Um usuário resolveu esse mesmo erro exato fazendo upgrade das imagens Docker de

1.3.1

para

1.5.1

(bootloader, server, webapp, worker). [Github Issue] Você pode compartilhar: • A versão do Airbyte/Helm Chart que está usando? • Os logs completos do pod

airbyte-bootloader

? • Está usando banco interno (bundled) ou externo? Isso ajudaria a identificar a causa raiz com mais precisão. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

estou usando um banco de dados postgres do tipo external @kapa.ai

Com banco externo, esse erro

Failed to access database

tem causas bem específicas. Com base nos casos documentados: Causas mais comuns com banco externo 1. Chave errada no

values.yaml

Um erro muito comum é usar

postgres:

em vez de

postgresql:

no Helm values. Isso faz o chart ignorar a configuração e tentar conectar no banco interno. [Github Issue] Certifique-se que está assim:

postgresql:
  enabled: false

global:
  database:
    type: external
    secretName: "airbyte-config-secrets"
    host: "seu-host-rds.amazonaws.com"
    port: "5432"
    database: "airbyte"
    userSecretKey: "database-user"
    passwordSecretKey: "database-password"

2. Variáveis de ambiente não sendo lidas corretamente Verifique se o pod do bootloader está realmente recebendo as variáveis do banco externo:

kubectl describe pod -n airbyte <airbyte-bootloader-pod>

Procure por

DATABASE_HOST

,

DATABASE_USER

,

DATABASE_URL

nas variáveis de ambiente. [Github Issue] 3. Problema de autenticação/senha Há relatos de a senha ser corrompida ou não ser lida corretamente do secret:

kubectl get secret airbyte-config-secrets -n airbyte -o yaml

Confirme que os valores estão em base64 correto. [Github Issue] 4. Firewall/Security Group bloqueando Mesmo que você consiga conectar externamente, os pods do Kubernetes podem estar bloqueados por security groups ou network policies. [Github Issue] Teste a conectividade de dentro do cluster:

kubectl exec -n airbyte <qualquer-pod> -- nc -zv <seu-host-db> 5432

5. Versão do PostgreSQL O Airbyte requer PostgreSQL 13. Versões diferentes podem causar incompatibilidades. [Forum Post] Você pode compartilhar a saída de

kubectl describe pod

do bootloader e os logs completos dele? Isso vai deixar claro se as variáveis estão sendo injetadas corretamente. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

{ "url": "https://airbyte.prd.data-platform.app.grupoboticario.com.br/workspaces/ee9b6a87-8775-4390-bcb5-a5b4dce9e25e/source", "airbyteVersion": "1.7.1", "errorType": "HttpError", "errorConstructor": "ru", "error": { "i18nKey": "errors.http.default", "i18nParams": { "status": 409 }, "name": "HttpError", "requestId": "d1jL23LnLd75LGbWTGWxoM", "request": { "url": "/api/v1/sources/list", "method": "POST", "headers": { "Content-Type": "application/json" }, "data": { "workspaceId": "ee9b6a87-8775-4390-bcb5-a5b4dce9e25e" } }, "status": 409, "response": { "message": "Failed to access database. Check the server logs for more information", "exceptionClassName": "io.airbyte.commons.server.errors.ConflictException", "exceptionStack": [], "rootCauseExceptionStack": [] } }, "stacktrace": "wx@https//airbyte.prd.data platform.app.grupoboticario.com.br/assets/core ebigvdmw88.js49:6790\nru@https//airbyte.prd.data platform.app.grupoboticario.com.br/assets/core ebigvdmw88.js49:7477\nRme@https//airbyte.prd.data platform.app.grupoboticario.com.br/assets/core ebigvdmw88.js56:1031\n", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:151.0) Gecko/20100101 Firefox/151.0", "featureFlags": {} } @kapa.ai

O erro HTTP 409 em

/api/v1/sources/list

com

Failed to access database

na versão 1.7.1 é o mesmo padrão já identificado anteriormente. [Github Issue] O que sabemos com certeza • O servidor Airbyte está rodando, mas falha ao executar queries no banco externo • O erro ocorre em uma chamada simples de listagem (

sources/list

), o que indica que o problema é persistente, não intermitente Próximos passos de diagnóstico 1. Verifique os logs do

airbyte-server

no momento do erro:

kubectl logs -n airbyte <airbyte-server-pod> --since=10m | grep -i "database\|error\|exception"

2. Verifique se o bootloader completou com sucesso:

kubectl logs -n airbyte <airbyte-bootloader-pod>

Procure por linhas como:

Current database migration version X.X.X
Database available.

3. Confirme que o pod está usando o banco externo:

kubectl describe pod -n airbyte <airbyte-server-pod> | grep -A2 "DATABASE_HOST\|DATABASE_URL\|DATABASE_USER"

Se

DATABASE_HOST

apontar para

airbyte-db-svc

(interno) em vez do seu host externo, a configuração não está sendo aplicada corretamente. [Github Issue] Checklist rápido do values.yaml Confirme que está exatamente assim (atenção ao

postgresql:

e não

postgres:

): [External Database docs]

postgresql:
  enabled: false

global:
  database:
    type: external
    secretName: "airbyte-config-secrets"
    host: "seu-host"
    port: "5432"
    name: "seu-database"
    userSecretKey: "database-user"
    passwordSecretKey: "database-password"

Os knowledge sources não contêm informação específica sobre esse erro na versão 1.7.1, então não posso afirmar com certeza se há um bug conhecido nessa versão. Compartilhe a saída dos logs do bootloader e do server para um diagnóstico mais preciso. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.