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 pode 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 forem gerados erros de tempo limite ou 504, verifique se o ambiente pode acessar *.composer.googleusercontent.com.

• (Somente Airflow gerenciado (2ª geração)) Problema de conectividade. Se a interface do Airflow estiver permanentemente indisponível e forem gerados erros de tempo limite ou 504, 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 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) são compatíveis apenas com a 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 (Gen 3) e do Airflow gerenciado (Gen 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 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 verticalmente para se ajustar aos dados armazenados pelas operações do Cloud SQL quando o banco de dados do Airflow cresce.

Não é possível reduzir escala vertical 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 após a 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:

• Se as vinculações de acesso baseado no contexto do Chrome Enterprise Premium forem usadas com níveis de acesso que dependem de atributos do dispositivo, e o Apache Airflow no app Airflow Gerenciado não estiver isento, não será possível acessar a interface do Airflow devido a um loop de login. Para permitir o acesso, siga as etapas em Permitir acesso à interface do Airflow em vinculações de acesso baseado no contexto.

• Se as regras de entrada estiverem configuradas em um perímetro do VPC Service Controls que protege o projeto, e a regra de entrada que permite o acesso ao serviço do Airflow gerenciado usar o tipo de identidade ANY_SERVICE_ACCOUNT ou ANY_USER_ACCOUNT, os usuários não poderão acessar a interface do Airflow, resultando em um loop de login. Para mais informações sobre como lidar com esse cenário, consulte Permitir acesso à interface do Airflow nas regras de entrada do VPC Service Controls.

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, é recomendável 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).

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:

• Iniciar 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 não recuperáveis, faça backup dos dados, por exemplo, criando um snapshot de um 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.

As imagens de contêiner de base dos builds afetados foram corrigidas, então os ambientes recém-criados não são afetados. Somente os ambientes que não atualizaram as imagens de contêiner desde 4 de novembro de 2026 continuam afetados.

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

Soluções:

Para mitigar esse problema em um ambiente atual, faça upgrade para uma imagem lançada em ou após 6 de novembro de 2026 (que inclui o google-api-core 2.43.1), faça upgrade para um dos seguintes builds (que incluem o google-api-core 2.27.0) ou siga as etapas de mitigação de autoatendimento em Versões de 2.30.3 a 2.43.0 no Python 3.11:

• 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

Observação: no Python 3.11, as versões 2.30.3 a 2.43.0 do google-api-core também causam um problema de desempenho na verificação de descontinuação a partir de 24 de outubro de 2026. Consulte 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 (assim como as versões 2.28.0 a 2.30.2) 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 é importada em um novo subprocesso do Python.

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

Status:

• Corrigido nas versões de 6 de novembro de 2026 e posteriores: as imagens composer-3-airflow-3.3.1-build.6, composer-3-airflow-3.2.2-build.10, composer-3-airflow-2.11.1-build.23, composer-2.17.17-airflow-2.11.1 e posteriores pré-instalam o google-api-core 2.43.1, que corrige esse problema.
• Imagens de base corrigidas para builds anteriores: as imagens de contêiner de base de todos os builds afetados listados nesta seção foram corrigidas em todas as regiões. Os ambientes recém-criados não são afetados, mesmo que você os crie com uma versão anterior.
• Ambientes atuais: os ambientes criados antes de 5 de novembro de 2026 continuam usando imagens de contêiner armazenadas em cache até que sejam atualizados por meio de manutenção programada ou de uma das etapas de mitigação nesta seção.

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 nos 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.

Antes da atualização da imagem, esse problema afetava os ambientes do Python 3.11 em que a versão 2.30.3 a 2.43.0 do google-api-core estava pré-instalada ou instalada manualmente, incluindo as seguintes versões.

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

• 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 a 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

Mitigação para ambientes atuais:

• Caminho rápido em asia-east1, asia-northeast2, europe-central2, me-central1, northamerica-northeast1 e us-south1: se o ambiente já tiver concluído uma janela de manutenção programada, defina ou atualize uma variável de ambiente de marcador de posição para reiniciar as cargas de trabalho do Airflow na infraestrutura de computação com patch:

  gcloud composer environments update ENVIRONMENT_NAME \
    --location LOCATION \
    --update-env-variables=COMPOSER_RELOAD=1
  

  Depois que a operação for concluída, verifique os registros do ambiente. Se as entradas FutureWarning de google/api_core/_python_version_support.py continuarem aparecendo em cargas de trabalho recém-iniciadas (por exemplo, se a manutenção programada ainda não tiver sido executada ou se o projeto usar o VPC Service Controls), aplique uma das opções para todas as regiões.

  Observação: no europe-north1, europe-west3, us-east1 e us-west2, a manutenção programada reinicia automaticamente as cargas de trabalho do Airflow que não são de worker (como programadores e processadores de DAG) em imagens com patch. Para atualizar os workers do Airflow imediatamente, aplique uma das opções a seguir.

• Todas as regiões: escolha uma das seguintes opções:

  • Opção 1: fazer upgrade do ambiente. Faça upgrade para um build não afetado, como composer-3-airflow-3.3.1-build.6, composer-3-airflow-3.2.2-build.10, composer-3-airflow-2.11.1-build.23 ou qualquer build mais recente com patch.

  • Opção 2: acionar uma atualização do pacote PyPI (requer acesso ao repositório PyPI). Atualize um pacote PyPI personalizado ou instale um pacote adicional para recriar a imagem do ambiente com base na imagem de base com patch e reiniciar todas as cargas de trabalho do Airflow.

    No composer-3-airflow-3.3.1-build.0 até o build.5, no composer-3-airflow-3.2.2-build.1 até o build.9 e no composer-3-airflow-3.1.8-build.3 até o build.4, é possível instalar o google-api-core>=2.43.1. Não instale o google-api-core>=2.43.1 em versões anteriores do Airflow 3 (3.2.2-build.0, 3.1.8-build.0 até build.2, 3.1.7, 3.1.0) ou em versões anteriores do Airflow 2, porque ele requer o opentelemetry-api>=1.44.0 e causa conflitos de dependência. Em vez disso, acione outra atualização do pacote PyPI.

• Opção 3 (solução alternativa sem fazer upgrade ou mudar os pacotes do PyPI): aplique um patch de ambiente de execução sitecustomize.py. Use essa opção se, por exemplo, seu ambiente usar o VPC Service Controls sem acesso ao repositório PyPI e não for possível fazer upgrade imediatamente:

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

     Importante: não modifique o arquivo para incluir as palavras airflow ou dag (inclusive em comentários), para que o modo de segurança de descoberta de DAG do Airflow o ignore.

  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: depois de fazer upgrade do ambiente ou recriar a imagem dele usando as etapas anteriores, remova a substituição de PYTHONPATH e exclua 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 vai acionar os erros 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

• Como resolver problemas da criação de ambientes
• Como resolver problemas de DAGs
• Como solucionar problemas do Airflow Scheduler