GitHub Actions troca o total exato por “2.500+” — ajuste suas consultas

No comunicado de 25 de setembro de 2026, o GitHub anunciou a distribuição de uma mudança: buscas filtradas com mais de 2.500 execuções do GitHub Actions passam a informar “2.500+” no lugar de um total exato. A alteração alcança a API e a interface em github.com e GitHub Enterprise Cloud. Para scripts e painéis que usam esse total em relatórios, a indicação passa a significar que a contagem ultrapassou um patamar, sem revelar o volume final.

A cobertura do WindowsForum, publicada no mesmo dia, distingue a mudança na contagem das buscas das execuções em si. Essa diferença delimita o impacto: a consulta continua retornando registros paginados, mas o total de uma busca grande já não pode ser tratado como número fechado. Uma rotina que apenas localiza execuções e outra que calcula métricas a partir do total exigem revisões diferentes.

Por que o total deixou de ser exato

A nova indicação vale para buscas de workflow runs filtradas por workflow, evento, status, branch ou actor. Quando a quantidade correspondente supera 2.500, “2.500+” informa que existem mais registros do que esse limite, sem dizer quantos. Usar 2.500 como se fosse o resultado final reduziria artificialmente uma soma e poderia fazer períodos com volumes distintos parecerem iguais.

A justificativa apresentada para a mudança são as consultas grandes que frequentemente expiravam durante a contagem. Elas podiam mostrar quantos registros haviam sido encontrados até o tempo limite, embora o número aparentasse ser um total completo. A indicação com sinal de mais elimina essa precisão enganosa para os resultados acima do patamar. Isso não prova que toda contagem antiga estava errada; mostra por que um número antigo de uma busca extensa não deve ser aceito automaticamente como base de auditoria.

O recorte da alteração também importa. O limite anunciado diz respeito ao total informado pela busca, não a uma interrupção das execuções nem à substituição dos registros individuais por uma contagem. Se um painel acompanha falhas ou atividade por branch, a pergunta relevante é como ele obtém o valor exibido: contando registros reunidos em consultas menores ou reutilizando o total de uma busca ampla.

O limite da contagem não é o limite da paginação

A referência da API REST para workflow runs estabelece até 1.000 resultados recuperáveis por busca com filtros como actor, branch, created, event ou status; o parâmetro per_page permite até 100 registros por página. O exemplo de resposta apresenta total_count como número, mas não mostra uma resposta acima do novo patamar. Portanto, a indicação “2.500+” não significa que uma busca filtrada passou a oferecer 2.500 registros para percorrer por páginas, nem permite concluir como o valor acima do limite será representado no JSON.

Para um painel, o problema pode aparecer como perda de precisão: o campo usado para comparar volumes deixa de fornecer uma quantidade exata quando a busca é grande. Para um coletor, a consequência é diferente. Calcular quantas páginas pedir a partir de um total amplo não supera o teto de registros recuperáveis da busca filtrada; mesmo que a contagem fosse conhecida, ela não faria os demais registros aparecerem nessa paginação.

Também há uma questão para clientes que exigem um tipo específico em total_count. Como as páginas consultadas não trazem um exemplo de resposta acima do limite, não há base para afirmar que a API colocará literalmente a string “2.500+” nesse campo, retornará um número limitado ou usará outra representação. Uma integração que converte o valor sem inspecionar a resposta efetiva pode falhar por um motivo distinto da perda de precisão do relatório.

Como dividir a busca com created

O parâmetro created restringe os resultados ao intervalo de data e hora de criação das execuções. Em um exemplo hipotético, um relatório mensal pode manter os mesmos filtros de workflow e branch e consultar separadamente cada semana do mês. Se uma semana ainda reunir execuções demais, o período pode ser repartido em dias ou em intervalos menores. O tamanho do recorte depende do volume encontrado, não de uma divisão fixa do calendário.

Há dois objetivos possíveis para essa divisão. Quem precisa de uma contagem numérica deve evitar intervalos que acionem a indicação “2.500+”. Quem precisa exportar todas as execuções deve usar intervalos pequenos o bastante para que a paginação da busca filtrada alcance todos os registros. Um recorte pode satisfazer o primeiro objetivo e ainda exceder o limite de resultados recuperáveis para o segundo.

As janelas precisam cobrir todo o período do relatório e preservar os demais critérios da consulta. Uma lacuna entre intervalos deixa execuções de fora; uma sobreposição pode contá-las duas vezes. Quando houver sobreposição, os identificadores das execuções permitem eliminar duplicatas dos registros reunidos. Somar buscas feitas com branches, status ou workflows diferentes também não reconstrói o total da busca original, ainda que cada resultado isolado pareça válido.

O exemplo de um mês dividido em semanas é apenas um ponto de partida. Se o volume varia muito entre dias, intervalos de duração igual podem produzir quantidades muito diferentes de resultados. A divisão precisa responder ao que cada consulta efetivamente retorna: para um relatório de totais, preservar contagens úteis; para uma exportação, garantir que cada conjunto de registros caiba no alcance da paginação.

Quais relatórios são afetados

Os primeiros candidatos à revisão são painéis que apresentam total_count como volume exato por workflow, branch, evento ou status. Acima do patamar, uma série histórica pode repetir “2.500+” em períodos com quantidades diferentes e ocultar a variação que deveria mostrar. Alertas e comparações numéricas baseados nesse total também podem deixar de distinguir volumes que ultrapassam o limite.

Rotinas de auditoria e exportação exigem uma avaliação separada: elas precisam saber se coletaram os registros necessários, não apenas se receberam uma contagem. Se calculam o número de páginas pelo total informado, convém confrontar essa lógica com o limite de resultados da busca filtrada. Se guardam apenas totais antigos, sem os identificadores das execuções, não é possível concluir pela aparência precisa do número que uma consulta extensa terminou sua contagem antes da mudança.

A distribuição anunciada abrange github.com e GitHub Enterprise Cloud. As páginas consultadas não detalham uma data de conclusão nem fornecem um exemplo do formato da resposta JSON acima do patamar. O estado confirmado é a nova semântica do total em buscas extensas; para relatórios que precisam de números ou registros completos, a divisão por created permite trabalhar com consultas menores dentro dos limites documentados.

Leia também:

• Vultus recebe R$ 8 milhões para trocar horas de consultoria por software
• Mudar de carreira por causa da IA? Comece pelas tarefas, não pelo cargo
• Memória do AgentCore expira por evento — mudar o prazo não salva o histórico