Problemas conhecidos com a Apigee

Quando a variável de fluxo cachehit é usada após a política LookupCache, devido à forma como os pontos de depuração são enviados para comportamento assíncrono, a LookupPolicy preenche o objeto DebugInfo antes que a chamada de retorno seja executada, resultando em um erro.

Solução alternativa:repita o processo (faça a segunda chamada) logo após a primeira.

A configuração de PurgeChildEntries na política InvalidateCache precisa limpar apenas os valores do elemento KeyFragment, mas limpa todo o cache.

Solução alternativa:use a política KeyValueMapOperations para iterar o versionamento do cache e contornar a necessidade de invalidação do cache.

Isso pode acontecer, por exemplo, quando execuções simultâneas de um pipeline de implantação de CI/CD ocorrem usando revisões diferentes. Para evitar esse problema, evite implantar proxies de API ou SharedFlows antes da conclusão da implantação atual.

Solução:evite implantações simultâneas de proxy de API ou SharedFlow.

Às vezes, as análises da API Edge podem conter dados duplicados para chamadas de API. Nesse caso, as contagens mostradas para chamadas de API no Edge API Analytics são maiores do que os valores comparáveis mostrados em ferramentas de análise de terceiros.

Solução alternativa:exporte os dados de análise e use o campo gateway_flow_id para remover a duplicação dos dados.

• O Apigee Edge é compatível com a especificação OpenAPI 3.0 quando você cria especificações usando o editor de especificação e publica APIs usando o SmartDocs no portal, embora um subconjunto de recursos ainda não seja compatível.

  Por exemplo, os recursos a seguir da especificação OpenAPI 3.0 ainda não são compatíveis:

  • Propriedades allOf para combinar e estender esquemas
  • Referências remotas

  Se um recurso incompatível for referenciado na especificação OpenAPI, em alguns casos, as ferramentas ignorarão o recurso, mas ainda assim renderizarão a documentação de referência da API. Em outros casos, um recurso não suportado causará erros que impedem a renderização bem-sucedida da documentação de referência da API. Em ambos os casos, você precisará modificar a especificação OpenAPI para evitar o uso do recurso não compatível até que ele seja compatível em uma versão futura.

  Observação: como o editor de especificação é menos restritivo que o SmartDocs ao renderizar a documentação de referência da API, os resultados podem ser diferentes entre as ferramentas.

• Ao usar o Testar esta API no portal, o cabeçalho Accept é definido como application/json, independentemente do valor definido para consumes na especificação OpenAPI.
• 138438484: Não há suporte para vários servidores.

• No momento, não há suporte para atualizações de portal simultâneas (como edições de página, tema, CSS ou script) de vários usuários.
• Se você excluir uma página de documentação de referência da API do portal, não será possível recriá-la. será necessário excluir e adicionar novamente o produto da API e gerar a documentação de referência da API novamente.
• Ao configurar a política de segurança de conteúdo, pode levar até 15 minutos para que as alterações sejam totalmente aplicadas.
• Ao personalizar seu tema do portal, pode levar até cinco minutos para que as alterações sejam aplicadas.

• A pesquisa será integrada ao portal integrado em uma versão futura.

Uma vulnerabilidade (CVE-2026-42945) foi divulgada afetando o ngx_http_rewrite_module no NGINX. As ferramentas de verificação de segurança podem sinalizar os binários do NGINX incluídos no Apigee Edge para nuvem privada porque esse módulo é compilado estaticamente no NGINX.

Impacto no Apigee Edge para nuvem privada :

O Apigee Edge para nuvem privada não é afetado por essa vulnerabilidade na configuração padrão enviada. A capacidade de exploração da CVE-2026-42945 depende de padrões de configuração específicos do NGINX, principalmente o uso da diretiva rewrite em uma sequência específica. Esses padrões não estão presentes em nenhuma configuração padrão do NGINX do Apigee Edge para nuvem privada.

Ação necessária :

• Para configurações padrão do Apigee Edge para nuvem privada:nenhum patch, upgrade ou mudança operacional é necessário. As descobertas do scanner relacionadas à CVE-2026-42945 podem ser tratadas como falsos positivos para instalações padrão. Você pode usar o texto a seguir para documentar essa exceção no sistema de gestão de vulnerabilidades:

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• Para configurações personalizadas do NGINX:se você modificou manualmente os arquivos de configuração do NGINX na instalação do Apigee Edge para nuvem privada (por exemplo, em /opt/nginx), faça a autoverificação a seguir para garantir que suas personalizações não tenham introduzido inadvertidamente o padrão vulnerável:
  1. Verifique a diretiva de reescrita:em cada nó do NGINX, execute o comando:

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. Analisar resultados:
     • Se o comando não retornar nenhuma saída, seu sistema não será afetado.
     • Se forem encontradas correspondências, revise cada instância. A vulnerabilidade está presente somente se todas as condições a seguir forem atendidas para um determinado bloco:
       • A diretiva rewrite é usada.
       • Ela é seguida imediatamente por outra diretiva rewrite, if ou set no mesmo bloco de configuração.
       • Um grupo de captura PCRE não nomeado (por exemplo, $1, $2 etc.) é usado nas diretivas.
       • A string de substituição na diretiva contém um ponto de interrogação (?).
  3. Mitigação (se vulnerável) : se todas as condições acima forem verdadeiras para qualquer parte da configuração personalizada, faça a mitigação:
     • Removendo o ponto de interrogação (?) da string de substituição.
     • Usando grupos de captura PCRE nomeados em vez de não nomeados.
     • Reavaliando a necessidade das diretivas encadeadas.

No Edge para nuvem privada 4.53.00 e versões mais recentes, a interface mostra um "Fim da vida útil" (EOL, na sigla em inglês) pop-up de aviso. Esse aviso aparece
repetidamente e não pode ser evitado ou reduzido em frequência.

No momento, não há um método disponível para os usuários desativarem ou reduzirem a frequência desse aviso de EOL.

Esse problema afeta apenas quem está usando o MINT ou tem o MINT ativado nas instalações do Edge para nuvem privada.

Componente afetado:edge-message-processor

Problema:se você tiver a monetização ativada e estiver instalando a versão 4.52.01 como uma instalação nova ou fazendo upgrade de versões anteriores da nuvem privada, vai encontrar um problema com os processadores de mensagens. Haverá um aumento gradual na contagem de threads abertos, levando ao esgotamento de recursos. A exceção a seguir é mostrada no system.log do edge-message-processor:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias implementações do protocolo HTTP/2 (CVE-2023-44487), incluindo o Apigee Edge para nuvem privada. A vulnerabilidade pode levar a um DoS da funcionalidade de gerenciamento da API Apigee. Para mais detalhes, consulte o boletim de segurança da Apigee GCP-2023-032.

Os componentes do roteador e do servidor de gerenciamento do Edge para nuvem privada estão expostos à Internet e podem estar vulneráveis. Embora o HTTP/2 esteja ativado na porta de gerenciamento de outros componentes específicos do Edge relativos ao Edge para nuvem privada, nenhum deles está exposto à Internet. Em componentes que não são do Edge, como Cassandra, Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que você siga as etapas a seguir para resolver a vulnerabilidade do Edge para nuvem privada:

• Etapas para o Edge para nuvem privada versões 4.51.00.11 ou mais recentes
• Etapas para o Edge para nuvem privada versões anteriores à 4.51.00.11

Siga estas etapas se estiver usando o Edge para nuvem privada versões 4.51.00.11 ou mais recentes:

1. Atualize o servidor de gerenciamento :

   1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do servidor de gerenciamento:

      apigee-service edge-management-server restart

2. Atualize o processador de mensagens :

   1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-message-processor restart

3. Atualize o roteador :

   1. Em cada nó do roteador, abra /opt/apigee/customer/application/router.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-router restart

4. Atualize o QPID :

   1. Em cada nó do QPID, abra /opt/apigee/customer/application/qpid-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-qpid-server restart

5. Atualize o Postgres :

   1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties
   2. Adicione esta linha ao arquivo de propriedades:

      conf_webserver_http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-postgres-server restart

Siga estas etapas se estiver usando o Edge para nuvem privada versões anteriores à 4.51.00.11:

1. Atualize o servidor de gerenciamento :

   1. Em cada nó do servidor de gerenciamento, abra /opt/apigee/customer/application/management-server.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do servidor de gerenciamento:

      apigee-service edge-management-server restart

2. Atualize o processador de mensagens :

   1. Em cada nó do processador de mensagens, abra /opt/apigee/customer/application/message-processor.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-message-processor restart

3. Atualize o roteador :

   1. Em cada nó do roteador, abra /opt/apigee/customer/application/router.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-router restart

4. Atualize o QPID :

   1. Em cada nó do QPID, abra /opt/apigee/customer/application/qpid-server.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-qpid-server restart

5. Atualize o Postgres :

   1. Em cada nó do Postgres, abra /opt/apigee/customer/application/postgres-server.properties
   2. Adicione as duas linhas a seguir ao arquivo de propriedades:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Reinicie o componente do processador de mensagens:

      apigee-service edge-postgres-server restart

O Apigee-postgresql está com problemas ao fazer upgrade do Edge para nuvem privada versão 4.50 ou 4.51 para a versão 4.52. Os problemas ocorrem principalmente quando o número de tabelas é maior que 500.

Para verificar o número total de tabelas no Postgres, execute a consulta SQL abaixo:

select count(*) from information_schema.tables

Solução alternativa: ao atualizar o Apigee Edge 4.50.00 ou 4.51.00 para 4.52.00, execute a etapa preliminar antes de fazer upgrade do Apigee-postgresql.

149245401: as configurações do pool de conexões LDAP para JNDI configuradas pelo recurso LDAP não são refletidas, e os padrões do JNDI causam conexões de uso único a cada vez. Como resultado, as conexões são abertas e fechadas a cada vez para uso único, criando um grande número de conexões por hora com o servidor LDAP.

Solução alternativa :

Para mudar as propriedades do pool de conexões LDAP, siga as etapas abaixo para definir uma mudança global em todas as políticas LDAP.

1. Crie um arquivo de propriedades de configuração, se ele ainda não existir:

   /opt/apigee/customer/application/message-processor.properties

2. Adicione o seguinte ao arquivo (substitua os valores das propriedades da Java Naming and Directory Interface (JNDI) com base no requisito de configuração do recurso LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Verifique se o arquivo /opt/apigee/customer/application/message-processor.properties pertence a apigee:apigee.
4. Reinicie cada processador de mensagens.

Para verificar se as propriedades JNDI estão entrando em vigor, você pode executar um tcpdump para observar o comportamento do pool de conexões LDAP ao longo do tempo.

139051927: as latências altas de processamento de proxy encontradas no processador de mensagens estão afetando todos os proxies de API. Os sintomas incluem atrasos de 200 a 300 ms nos tempos de processamento em relação aos tempos de resposta normais da API e podem ocorrer aleatoriamente, mesmo com TPS baixo. Isso pode ocorrer quando há mais de 50 servidores de destino em que um processador de mensagens faz conexões.

Causa raiz: Os processadores de mensagens mantêm um cache que mapeia o URL do servidor de destino para o objeto HTTPClient para conexões de saída com servidores de destino. Por padrão, essa configuração é definida como 50, o que pode ser muito baixo para a maioria das implantações. Quando uma implantação tem várias combinações de organização/ambiente em uma configuração, e um grande número de servidores de destino que excedem 50 no total, os URLs do servidor de destino continuam sendo removidos do cache, causando latências.

Validação: Para determinar se a remoção do URL do servidor de destino está causando o problema de latência, pesquise as palavras-chave "onEvict" ou "Eviction" nos system.logs do processador de mensagens. A presença delas nos registros indica que os URLs do servidor de destino estão sendo removidos do cache HTTPClient porque o tamanho do cache é muito pequeno.

Solução alternativa: Para o Edge para nuvem privada versões 19.01 e 19.06, é possível editar e configurar o cache HTTPClient, /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Em seguida, reinicie o processador de mensagens. Faça as mesmas mudanças para todos os processadores de mensagens.

O valor 500 é um exemplo. O valor ideal para sua configuração precisa ser maior que o número de servidores de destino a que o processador de mensagens se conectaria. Não há efeitos colaterais ao definir essa propriedade como maior, e o único efeito seria uma melhoria nos tempos de processamento de solicitações de proxy do processador de mensagens.

Observação:o Edge para nuvem privada versão 50.00 tem a configuração padrão de 500.

157933959: inserções e atualizações simultâneas no mesmo mapa de chave-valor (KVM) com escopo para a organização ou o ambiente causam dados inconsistentes e atualizações perdidas.

Observação:essa limitação se aplica apenas ao Edge para nuvem privada. O Edge para nuvem pública e híbrida não tem essa limitação.

Para uma solução alternativa no Edge para nuvem privada, crie o KVM no apiproxy escopo.