Problemas conhecidos

Airflow gerenciado (geração 3) | Airflow gerenciado (geração 2) | Airflow gerenciado (geração 1 legada)

Nesta página, listamos os problemas conhecidos do Airflow Gerenciado. Para informações sobre correções de problemas, consulte as Notas da versão.

A primeira execução do DAG para um arquivo DAG enviado tem várias tarefas com falha

Quando você faz o upload de um arquivo DAG, às vezes as primeiras tarefas da primeira execução do DAG falham com o erro Unable to read remote log.... Esse problema ocorre porque o arquivo DAG é sincronizado entre o bucket do ambiente, os workers do Airflow e os programadores do Airflow do ambiente. Se o programador receber o arquivo DAG e programá-lo para ser executado por um worker, e se o worker ainda não tiver o arquivo DAG, a execução da tarefa vai falhar.

Para mitigar esse problema, os ambientes com o Airflow 2 são configurados para realizar duas novas tentativas para uma tarefa com falha por padrão. Se uma tarefa falhar, ela será repetida duas vezes com intervalos de 5 minutos.

O Airflow Gerenciado não deve ser afetado pela vulnerabilidade do Apache Log4j 2 (CVE-2021-44228)

Em resposta à vulnerabilidade do Apache Log4j 2 (CVE-2021-44228), o Airflow Gerenciado realizou uma investigação detalhada e acreditamos que ele não é vulnerável a essa exploração.

Às vezes, a interface do Airflow pode não recarregar um plug-in depois que ele é alterado

Se um plug-in consistir em muitos arquivos que importam outros módulos, a interface do Airflow poderá não reconhecer que um plug-in precisa ser recarregado. Nesse caso, reinicie o servidor da Web do Airflow do seu ambiente.

Erro 504 ao acessar a interface do Airflow

Você pode receber o erro 504 Gateway Timeout ao acessar a interface do Airflow. Esse erro pode ter várias causas:

  • Problema de comunicação temporário. Nesse caso, tente acessar a interface do Airflow mais tarde. Também é possível reiniciar o servidor da Web do Airflow.

  • (Somente Airflow gerenciado (Geração 3)) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e erros de tempo limite ou 504 forem gerados, verifique se o ambiente pode acessar *.composer.googleusercontent.com.

  • (Somente Airflow gerenciado (Geração 2)) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e erros de tempo limite ou 504 forem gerados, verifique se o ambiente pode acessar *.composer.cloud.google.com. Se você usa o Acesso privado do Google e envia tráfego por IPs virtuais private.googleapis.com ou o VPC Service Controls e envia tráfego por IPs virtuais restricted.googleapis.com, verifique se o Cloud DNS também está configurado para nomes de domínio *.composer.cloud.google.com.

  • Servidor da Web do Airflow que não responde. Se o erro 504 persistir, mas você ainda conseguir acessar a interface do Airflow em determinados momentos, o servidor da Web do Airflow pode não estar respondendo porque está sobrecarregado. Tente aumentar os parâmetros de escala e desempenho do servidor da Web.

Erro 502 ao acessar a interface do Airflow

O erro 502 Internal server exception indica que a interface do Airflow não pode atender às solicitações recebidas. Esse erro pode ter várias causas:

  • Problema de comunicação temporário. Tente acessar a interface do Airflow mais tarde.

  • Falha ao iniciar o servidor da Web. Para iniciar, o servidor da Web exige que os arquivos de configuração sejam sincronizados primeiro. Verifique se há entradas de registro semelhantes a GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp ou GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp nos registros do servidor da Web. Se você receber esses erros, verifique se os arquivos mencionados nas mensagens de erro ainda estão presentes no bucket do ambiente.

    Em caso de remoção acidental (por exemplo, porque uma política de retenção foi configurada), é possível restaurá-los:

    1. Defina uma nova variável de ambiente no seu ambiente. Você pode usar qualquer nome e valor de variável.

    2. Substituir uma opção de configuração do Airflow. É possível usar uma opção de configuração do Airflow que não existe.

Erro 500 ao acessar a interface do Airflow depois de substituir [webserver]analytics_tool

Em ambientes com o Airflow 2, se você substituir a opção de configuração [webserver]analytics_tool do Airflow para rotear dados anônimos de uso da interface do Airflow para um serviço de análise (como Google Analytics, Segment, MetaRouter ou Matomo), o acesso à interface do Airflow após a atualização do ambiente pode retornar uma resposta (500) Internal Server Error, com um dos seguintes erros nos registros do servidor da Web do Airflow:

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

Quando [webserver]analytics_tool é definido no Airflow 2, o servidor da Web do Airflow exige que as opções de análise associadas na seção [webserver] também sejam definidas ao renderizar a interface do Airflow.

No Airflow 3, as opções de configuração [webserver]analytics_tool, [webserver]analytics_id e [webserver]analytics_url foram removidas.

Soluções:

  • Remova a substituição da opção de configuração do Airflow [webserver]analytics_tool ou
  • Especifique todas as opções de configuração obrigatórias do Airflow juntas:
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url (obrigatório no Airflow 2.9 e versões mais recentes, mesmo que sua ferramenta de análise não use um URL personalizado)

Passar o cursor sobre a instância da tarefa na visualização em árvore gera um TypeError não detectado

No Airflow 2, a visualização em árvore na interface do Airflow pode não funcionar corretamente quando um fuso horário não padrão é usado. Como solução alternativa para esse problema, configure o fuso horário explicitamente na interface do Airflow.

Pastas vazias em Scheduler e Workers

O Airflow gerenciado não remove ativamente pastas vazias dos workers e programadores do Airflow. Essas entidades podem ser criadas como resultado do processo de sincronização do bucket do ambiente quando essas pastas existiam no bucket e foram removidas.

Recomendação: ajuste os DAGs para que eles estejam preparados para pular essas pastas vazias.

Essas entidades são removidas dos armazenamentos locais de programadores e workers do Airflow quando esses componentes são reiniciados (por exemplo, como resultado de operações de redução de escala vertical ou manutenção no cluster do ambiente).

Suporte para Kerberos

O Airflow gerenciado não é compatível com a configuração do Airflow Kerberos.

Suporte para classes de computação no Airflow Gerenciado (Geração 2) e no Airflow Gerenciado (Geração 3)

O Airflow Gerenciado (Gen 3) e o Airflow Gerenciado (Gen 2) oferecem suporte apenas à classe de computação de uso geral. Isso significa que não é possível executar pods que solicitam outras classes de computação, como Balanced ou Scale-Out.

A classe de uso geral permite executar pods que solicitam até 110 GB de memória e até 30 CPUs (conforme descrito em Solicitações máximas de classe de computação).

Se você quiser usar uma arquitetura baseada em ARM ou precisar de mais CPU e memória, use uma classe de computação diferente, que não é compatível com os clusters do Airflow gerenciado (geração 3) e do Airflow gerenciado (geração 2).

Recomendação: use GKEStartPodOperator para executar pods do Kubernetes em um cluster diferente que seja compatível com a classe de computação selecionada. Se você executar pods personalizados que exigem uma classe de computação diferente, eles também precisarão ser executados em um cluster do Airflow não gerenciado.

Não é possível reduzir o armazenamento do Cloud SQL

O Airflow Gerenciado usa o Cloud SQL para executar o banco de dados do Airflow. Com o tempo, o armazenamento em disco da instância do Cloud SQL pode aumentar porque o disco é escalonado para acomodar os dados armazenados pelas operações do Cloud SQL quando o banco de dados do Airflow cresce.

Não é possível reduzir o tamanho do disco do Cloud SQL.

Como solução alternativa, se você quiser usar o menor tamanho de disco do Cloud SQL, recrie os ambientes do Airflow Gerenciado com snapshots.

A métrica de uso do disco do banco de dados não diminui depois da remoção de registros do Cloud SQL

Os bancos de dados relacionais, como Postgres ou MySQL, não removem fisicamente as linhas quando elas são excluídas ou atualizadas. Em vez disso, ele as marca como "tuplas mortas" para manter a consistência dos dados e evitar o bloqueio de transações simultâneas.

O MySQL e o Postgres implementam mecanismos de recuperação de espaço após a exclusão de registros.

Embora seja possível forçar o banco de dados a recuperar o espaço em disco não utilizado, essa é uma operação que consome muitos recursos e que também bloqueia o banco de dados, tornando o Airflow Gerenciado indisponível. Portanto, é recomendável confiar nos mecanismos de criação para recuperar o espaço não utilizado.

Acesso bloqueado: erro de autorização

Se esse problema afetar um usuário, a caixa de diálogo Acesso bloqueado: erro de autorização vai conter a mensagem Error 400: admin_policy_enforced.

Se a opção Controles de API > Apps de terceiros não configurados > Não permitir que os usuários acessem apps de terceiros estiver ativada no Google Workspace e o Apache Airflow no app Airflow gerenciado não for explicitamente permitido, os usuários não poderão acessar a interface do Airflow, a menos que permitam explicitamente o aplicativo.

Para permitir o acesso, siga as etapas em Permitir acesso à interface do Airflow no Google Workspace.

Loop de login ao acessar a interface do Airflow

Esse problema pode ter as seguintes causas:

A pasta /data não está disponível no servidor da Web do Airflow

No Airflow Gerenciado (Geração 2) e no Airflow Gerenciado (Geração 3), o servidor da Web do Airflow é um componente somente leitura, e o Airflow Gerenciado não sincroniza a pasta data/ com esse componente.

Às vezes, é útil compartilhar arquivos comuns entre todos os componentes do Airflow, incluindo o servidor da Web do Airflow.

Solução:

  • Encapsule os arquivos a serem compartilhados com o servidor da Web em um módulo PYPI e instale-o como um pacote PYPI comum. Depois que o módulo PYPI é instalado no ambiente, os arquivos são adicionados às imagens dos componentes do Airflow e ficam disponíveis para eles.

  • Adicione arquivos à pasta plugins/. Essa pasta é sincronizada com o servidor da Web do Airflow.

Diagramas de tempos de análise de DAG não contínuos e tamanho do conjunto de DAGs no monitoramento

Os diagramas de tempos de análise de DAG não contínuos e de tamanho de bolsa de DAG no painel de monitoramento indicam problemas com tempos de análise de DAG longos (mais de 5 minutos).

Gráficos de tempos de análise de DAG do Airflow e tamanho do conjunto de DAGs mostrando uma série de intervalos não contínuos
Figura 1. Gráficos de tempos de análise de DAG não contínuos e tamanho do repositório de DAG (clique para ampliar)

Solução: recomendamos manter o tempo total de análise do DAG em menos de 5 minutos. Para reduzir o tempo de análise do DAG, siga as diretrizes de gravação do DAG.

Os registros de tarefas aparecem com atrasos

Sintoma:

  • No Airflow Gerenciado (3ª geração), os registros de tarefas do Airflow não aparecem imediatamente e são atrasados por alguns minutos.
  • Talvez você encontre mensagens Logs not found for Cloud Logging filter nos registros do Airflow

Causa:

Se o ambiente executar um grande número de tarefas ao mesmo tempo, os registros de tarefas poderão ser atrasados porque o tamanho da infraestrutura do ambiente não é suficiente para processar todos os registros com rapidez suficiente.

Soluções:

  • Considere aumentar o tamanho da infraestrutura do ambiente para melhorar o desempenho.
  • Distribua as execuções do DAG ao longo do tempo para que as tarefas não sejam executadas ao mesmo tempo.

Aumento dos tempos de inicialização do KubernetesPodOperator e do KubernetesExecutor

Os pods criados com o KubernetesPodOperator e as tarefas executadas com o KubernetesExecutor têm tempos de inicialização maiores. A equipe do Airflow Gerenciado está trabalhando em uma solução e vai anunciar quando o problema for resolvido.

Alternativas:

  • Inicie pods com mais CPU.
  • Se possível, otimize as imagens (menos camadas, tamanho menor).

O ambiente está no estado de erro depois que a conta de faturamento do projeto foi excluída ou desativada ou a API Cloud Composer foi desativada

Os ambientes do Airflow gerenciado afetados por esses problemas não são recuperáveis:

  • Depois que a conta de faturamento do projeto foi excluída ou desativada, mesmo que outra conta tenha sido vinculada posteriormente.
  • Depois que a API Cloud Composer foi desativada no projeto, mesmo que tenha sido ativada posteriormente.

Para resolver o problema, faça o seguinte:

  • Ainda é possível acessar os dados armazenados nos buckets do ambiente, mas os ambientes em si não podem mais ser usados. É possível criar um novo ambiente do Airflow Gerenciado e transferir seus DAGs e dados.

  • Se você quiser realizar qualquer uma das operações que tornam seus ambientes irrecuperáveis, faça backup dos dados, por exemplo, criando um snapshot do ambiente. Dessa forma, é possível criar outro ambiente e transferir os dados dele carregando esse snapshot.

Os registros de tarefas do Airflow não serão coletados se [core]execute_tasks_new_python_interpreter estiver definido como True

O Airflow Gerenciado não coleta registros de tarefas do Airflow se a opção de configuração [core]execute_tasks_new_python_interpreter estiver definida como True.

Possível solução:

  • Remova a substituição dessa opção de configuração ou defina o valor como False.

Erro ao remover o anexo de rede quando um ambiente é excluído

Se vários ambientes que compartilham o mesmo anexo de rede forem excluídos ao mesmo tempo, algumas operações de exclusão vão falhar com um erro.

Sintomas:

O seguinte erro é gerado:

Got error while removing Network Attachment: <error code>

O código do erro informado pode ser Bad request: <resource> is not ready ou Precondition failed: Invalid fingerprint.

Possíveis soluções alternativas:

  • Exclua os ambientes que usam o mesmo anexo de rede um por um.

  • Desative a conexão com uma rede VPC para seus ambientes antes de excluí-los. Recomendamos essa solução alternativa para exclusão automatizada de ambientes.

Desempenho degradado do ambiente em várias versões do pacote google-api-core

Versões de 2.28.0 a 2.30.2

As versões do pacote pré-instalado google-api-core de 2.28.0 a 2.30.2 podem causar degradação do desempenho do ambiente, o que pode resultar em tempos mais longos para executar uma tarefa e tempos mais longos para mover uma tarefa do estado na fila para o estado de execução.

Builds do Airflow gerenciado (3ª geração) afetados:

  • composer-3-airflow-3.1.7-build.0 para composer-3-airflow-3.1.7-build.5
  • composer-3-airflow-3.1.0-build.5 para composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • composer-3-airflow-2.10.5-build.22 para composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 para composer-3-airflow-2.9.3-build.53

Builds do Airflow gerenciado (2ª geração) afetados:

  • composer-2.16.10-airflow-2.11.1
  • composer-2.16.0-airflow-2.10.5 para composer-2.16.10-airflow-2.10.5
  • composer-2.16.0-airflow-2.9.3 para composer-2.16.10-airflow-2.9.3

Faça upgrade do ambiente para uma das seguintes versões, que incluem o google-api-core versão 2.27.0 pré-instalado e não são afetadas por esse problema:

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

Como alternativa, faça upgrade para uma imagem que inclua o google-api-core 2.43.1 ou mais recente ou instale manualmente uma versão compatível.

No Python 3.11, as versões 2.30.3 a 2.43.0 do google-api-core causam um problema de desempenho separado a partir de 24 de outubro de 2026. Se o ambiente executar o Python 3.11, aplique uma das soluções alternativas listadas em Versões de 2.30.3 a 2.43.0 no Python 3.11.

Versões de 2.30.3 a 2.43.0 no Python 3.11

A partir de 24 de outubro de 2026, as versões 2.30.3 a 2.43.0 do pacote google-api-core vão executar uma verificação de descontinuação do Python 3.11 que analisa os metadados do pacote instalado sempre que uma biblioteca de cliente do Google Cloud for importada em um novo subprocesso do Python.

Em ambientes do Airflow Gerenciado que executam o Python 3.11, esse comportamento pode prejudicar o desempenho. Esse problema é mais grave em ambientes com muitos DAGs, tarefas frequentes de curta duração ou integração de linhagem de dados ativada.

Os sintomas incluem:

  • Aumento dos tempos de análise de DAG e maior uso da CPU nos processadores de DAG do Airflow.
  • Tempos de execução de tarefas mais longos e maior uso de CPU em workers do Airflow.
  • Entradas de registro frequentes de FutureWarning de google/api_core/_python_version_support.py informando que o suporte ao Python 3.11 termina em 24/10/2027.

Esse problema afeta qualquer ambiente do Python 3.11 em que a versão 2.30.3 a 2.43.0 do google-api-core esteja pré-instalada ou instalada manualmente, incluindo os builds a seguir.

Esse problema afeta as seguintes versões do Airflow gerenciado (3ª geração):

  • composer-3-airflow-3.3.1-build.0 para composer-3-airflow-3.3.1-build.5
  • composer-3-airflow-3.2.2-build.0 para composer-3-airflow-3.2.2-build.9
  • composer-3-airflow-3.1.8-build.0 para composer-3-airflow-3.1.8-build.4
  • composer-3-airflow-3.1.7-build.7 para composer-3-airflow-3.1.7-build.13
  • composer-3-airflow-2.11.1-build.3 para composer-3-airflow-2.11.1-build.22
  • composer-3-airflow-2.10.5-build.36 para composer-3-airflow-2.10.5-build.52

Builds do Airflow gerenciado (2ª geração) afetados:

  • composer-2.17.0-airflow-2.11.1 para composer-2.17.16-airflow-2.11.1
  • composer-2.17.0-airflow-2.10.5 para composer-2.17.13-airflow-2.10.5

Alternativas:

Escolha uma das seguintes opções com base na versão de imagem do seu ambiente:

  • Opção 1. Builds compatíveis do Airflow gerenciado (Gen 3) somente com o Airflow 3: instale o pacote PyPI google-api-core com a restrição de versão >=2.43.1.

    Builds compatíveis do Airflow Gerenciado (3ª geração):

    • composer-3-airflow-3.3.1-build.0 para composer-3-airflow-3.3.1-build.5
    • composer-3-airflow-3.2.2-build.1 a composer-3-airflow-3.2.2-build.9
    • composer-3-airflow-3.1.8-build.3 para composer-3-airflow-3.1.8-build.4

    Não use essa opção em builds do Airflow 2 ou anteriores do Airflow 3, incluindo composer-3-airflow-3.2.2-build.0 e composer-3-airflow-3.1.8-build.0 até build.2. Nessas versões, o google-api-core 2.43.1 causa conflitos de dependência porque requer opentelemetry-api>=1.44.0. Para essas versões, use a Opção 2.

  • Opção 2. Todas as versões afetadas do Airflow Gerenciado (Geração 3) e do Airflow Gerenciado (Geração 2): aplique um patch de ambiente de execução sitecustomize.py.

    1. Faça o download de sitecustomize.py no GitHub.

    2. Faça upload de sitecustomize.py para a pasta dags/patches no bucket do ambiente.

    3. Defina a variável de ambiente PYTHONPATH como /home/airflow/gcs/dags/patches.

      Se PYTHONPATH já estiver definido, adicione /home/airflow/gcs/dags/patches: ao valor atual. Exemplo: /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    Limpeza após um upgrade: em versões futuras do Airflow gerenciado, a versão 2.43.1 ou mais recente do pacote google-api-core será pré-instalada. Depois de fazer upgrade para uma imagem com o google-api-core 2.43.1 ou posterior, é possível remover a substituição de PYTHONPATH e excluir dags/patches/sitecustomize.py.

A TI não está mais no estado de execução, e a tarefa precisa ser encerrada, além de erros de tarefa não encontrada no Airflow 3

O Airflow 3 tem dois problemas relacionados à perda do estado da tarefa pelo programador durante as reinicializações:

  • Status de conflito 409: uma disputa nos programadores causa a programação de instâncias de tarefas duplicadas (#59378, resolvido em #60330).

    Esse problema foi corrigido no Airflow 3.2.2.

  • Erro 404 Não encontrado: os workers do Airflow perdem o controle das instâncias de tarefa durante uma reinicialização regular do loop do programador, que acontece depois que o programador atinge [scheduler]num_runs. Isso muda os IDs de instância de tarefa atuais e gera erros 404 subsequentes de um worker que não está ciente da mudança ( #53140, #60330, resolvido em #61631).

    Esse problema foi corrigido no Airflow 3.3.1.

Sintomas

  • 409 Conflict: o estado de limpeza órfão de um programador reiniciado marca as tarefas ativas como FAILED, fazendo com que os workers sejam encerrados de forma anormal:

    Server indicated the task shouldn't be running anymore [supervisor]
detail={'detail': {'reason': 'not_running', 'message': 'TI is no longer in
the running state and task should terminate', 'current_state': 'scheduled'}} status_code=409 ti_id=UUID('...')

  • 404 Não encontrado: um programador reiniciado perde os estados da tarefa e falha nas verificações de pulso do worker ativo:

    Server indicated the task shouldn't be running anymore [detail={'detail':
{'reason': 'not_found', 'message': 'Task Instance not found'}}]
[status_code=404] [ti_id=...]

Solução:

  • Os dois problemas foram corrigidos na versão 3.3.1 e posteriores do Airflow. Faça upgrade do ambiente para uma versão que use o Airflow 3.3.1.

Possíveis soluções alternativas:

  • Não é possível mitigar completamente o problema em versões do Airflow anteriores à 3.3.1. Qualquer evento externo que faça com que um único programador seja reiniciado inesperadamente acionará 404 e 409 (nas versões do Airflow anteriores à 3.2.2). Exemplos desses eventos são upgrades automáticos de nós no cluster do ambiente, condições de OOM em pods ou alto consumo de memória e CPU por programadores.

  • Reduzir o ambiente para um programador e definir a opção de configuração [scheduler]num_runs como -1 reduz a causa de disputas nos programadores.

    Para um ambiente altamente resiliente (alta disponibilidade), não é possível reduzir o número de programadores para um. Ainda é possível definir o [scheduler]num_runs como -1.

  • Verifique se o consumo de memória e CPU pelo programador está dentro dos limites de recursos disponíveis.

A seguir