fix: corrige 3 bugs criticos em search, stats e filtro de status#1
Open
FabricioZacchi wants to merge 1 commit into
Open
fix: corrige 3 bugs criticos em search, stats e filtro de status#1FabricioZacchi wants to merge 1 commit into
FabricioZacchi wants to merge 1 commit into
Conversation
Bug 1 – getTicketStats() com dados errados em bases com >10.000 tickets:
A implementação anterior carregava os primeiros 10.000 tickets (range 0-9999)
e filtrava em memória. Em ambientes com muitos tickets, os registros mais antigos
(todos com status 'closed') preenchiam o range, zerando new/processing/pending/solved.
Corrigido usando a API de search com range=0-0 por status, consumindo apenas o
campo totalcount — sem transferir dados dos tickets.
Bug 2 – glpi_search retornando respostas massivas (8MB+):
O método search() não aplicava range na requisição, fazendo o GLPI retornar
até 150 itens com todos os campos (incluindo conteúdo HTML), gerando respostas
de 8MB que inviabilizavam o uso com LLMs. Corrigido adicionando suporte a
options.limit no método search() e aplicando range=0-{limit-1}. A tool
glpi_search agora tem limit padrão de 20 itens e retorna totalcount + paginação.
Bug 3 – glpi_list_tickets ignorando o filtro de status:
O parâmetro status era recebido pela tool mas nunca passado para getTickets(),
que por sua vez não suporta filtro de status via getItems(). A consulta retornava
tickets de qualquer status independente do filtro informado. Corrigido usando
a API de search com field=12 (status) quando o parâmetro status é fornecido.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Descrição
Este PR corrige 3 bugs críticos identificados em produção com mais de 10.000 tickets no GLPI.
🐛 Bug 1 — retorna dados errados
Sintoma em produção:
Causa raiz: carregava os primeiros 10.000 tickets () e filtrava em memória. Em bases com mais de 10.000 tickets, a API GLPI ordena por ID ASC, retornando apenas os mais antigos (todos ). Tickets ativos ficam além da posição 10.000 e nunca são contabilizados.
Correção: 6 requisições paralelas à API de search com por status, consumindo apenas o campo — sem transferir dados dos tickets.
🐛 Bug 2 — retorna respostas de 8MB+
Sintoma em produção: nos logs do MCP.
Causa raiz: O método não passava o parâmetro à API GLPI, que retornava até 150 itens com todos os campos (incluindo conteúdo HTML completo dos tickets).
Correção: Adicionado ao método com aplicação de . Padrão de 20 itens. A tool agora retorna e informação de paginação.
🐛 Bug 3 — ignora o filtro de
Sintoma em produção: Filtrar por (New) retornava tickets com status Solved e Processing.
Causa raiz: O parâmetro era recebido pela tool mas nunca passado para . O endpoint não suporta filtro de status, que era silenciosamente ignorado.
Correção: Quando é fornecido, usa a API de search com (campo status no GLPI), garantindo filtro correto no servidor.
Arquivos modificados
Testado em GLPI com mais de 10.000 tickets, mcp-glpi v2.0.0, Node.js 20.