📋 Auditoria de Requisições IXC

• Arquivo: painel-tecnico-mark3/backend/src/ixc/client.js:12 (ixcListar) — usa fetch() nativo do Node (undici), sem header User-Agent custom → undici manda UA padrão node. Bate com o log.
• Endpoint: cliente_contrato (linha 272, fetchContratoMap) — bate exato com o log.
• Cadeia de disparo:
  • Frontend SugestoesAntecipacao.jsx faz polling a cada 15s (usePolling, intervalo padrão) — rodando o tempo todo enquanto a aba/TV com o painel Mark3 estiver aberta.
  • Cada poll roda buildResumoSinalAltoPreventiva (sinalAltoPreventiva.js:162) → ociosos.map(t => candidatosParaTecnico(...)) em paralelo, 1 chamada por técnico ocioso.
  • Cada candidatosParaTecnico (linha 72) chama fetchContratoMap(dentroDoRaio...) (linha 267), que faz Promise.all(unicos.map(id => ixcListar('cliente_contrato', ...))) — sem limite de concorrência nenhum (nem os 6 workers que o resto do código usa). Com 5 técnicos ociosos e ~20 contratos cada dentro do raio, é ~100 requisições simultâneas, repetidas a cada 15s.
  • Mesma cadeia também bate em cliente (fetchClienteEnderecoMap, linha 297) e cliente_condominio (fetchCondominioMap, linha 321) — mesmo padrão sem limite.
• Proteção existente: só a base ONU (fetchClientesSinalAlto, ~439 registros) tem cache de 3min + dedupe de inflight. Essa proteção não cobre fetchContratoMap/fetchClienteEnderecoMap/fetchCondominioMap.
• Volume estimado: dezenas a ~100+ requisições por ciclo de 15s, continuamente, o dia inteiro, enquanto o painel Mark3 (Sinal Alto Preventiva / Sugestões de Antecipação) estiver aberto.
• Recomendação: cache + limite de concorrência em fetchContratoMap/fetchClienteEnderecoMap/fetchCondominioMap (mesmo padrão do _inflight/cache já usado em fetchClientesSinalAlto); considerar aumentar o intervalo de polling do frontend. Não aplicado ainda — só mapeado.

Nenhum teste ao vivo contra o IXC foi feito pra validar isso — validação abaixo é 100% por leitura de código + simulação com fetch mockado (contagem de chamadas/concorrência antes x depois). Teste real único, coordenado, fica pra combinar.

• Arquivo: backend/src/ixc/client.js — fetchContratoMap, fetchClienteEnderecoMap, fetchCondominioMap, fetchClienteNomeMap + fetchClienteMap (5 funções no total — as 2 últimas não estavam na lista original, mesmo problema, incluídas ao longo do trabalho).
• Antes: Promise.all(unicos.map(id => ixcListar(...))) — sem cache, sem limite de concorrência. Cada função dispara N requisições simultâneas (N = ids únicos), e como roda 1x por técnico ocioso em paralelo, os N se multiplicam por técnico.
• Depois: cache por ID com TTL de 3min (mesmo TTL já usado em fetchClientesSinalAlto) + semáforo global do processo (não por função, não por técnico) limitando a 4 requisições em voo ao mesmo tempo — cobre a composição N-técnicos × M-ids com um limite só, sem precisar mexer no loop de técnicos em sinalAltoPreventiva.js.
• Intervalo de polling: o componente que realmente dispara o pipeline pesado é SinalAltoPreventiva.jsx (rota GET /sinal-alto-preventiva) — usePolling(..., 30000) → 90000 (30s → 90s; achado tardio, corrigido antes do teste ao vivo — o ajuste inicial em SugestoesAntecipacao.jsx, 15s→90s, também ficou, mas era o componente errado pro pipeline pesado; mantido por reduzir carga de fetchClienteMap na rota /sugestoes).
• Validação: simulação com fetch mockado (contador de chamadas + concorrência máxima observada), sem bater no IXC real:

  Cenário	Antes (estimado)	Depois (medido na simulação)
  1 técnico ocioso, 20 contratos no raio, cache frio	20 requisições simultâneas	20 requisições, máx. 4 simultâneas
  Mesmo técnico, ciclo seguinte (dentro do TTL de 3min)	20 requisições de novo (sem cache)	0 requisições (cache)
  5 técnicos ociosos em paralelo, 100 contratos novos no total	~100 requisições simultâneas	100 requisições, máx. 4 simultâneas (nunca mais que 4 em voo)
  Ciclo de polling	A cada 15s, indefinidamente	A cada 90s (6x menos ciclos/hora)

Estimativa de redução: pico de ~100 requisições simultâneas → no máximo 4 em voo a qualquer instante, e a maior parte dos ciclos depois do 1º vira 0 requisições novas (cache de 3min) em vez de repetir tudo a cada 15s. Frequência de ciclo também caiu 6x (15s → 90s).

Deploy: painel-mark3-backend.service reiniciado e frontend rebuildado/redeployado em produção às 14:26 de 01/09/2026 (autorizado). Serviço voltou no ar sem erro, 0 restarts desde então, /health respondendo normal. Nenhum teste que gera carga real foi feito — aguardando confirmação de horário combinado com o Nalberth antes do teste ao vivo coordenado.

Evidência adicional encontrada no log do processo antes do restart (13:20–13:22 de 01/09/2026, poucos minutos antes do deploy): múltiplos unhandledRejection com o corpo de erro literal do IXC — "Too many connections" (MySQL) — nas 3 chamadas (cliente_contrato, cliente, cliente_condominio), inclusive um Promise.all (index 123) em fetchContratoMap às 13:22:07 — confirma ao vivo, com o código antigo ainda rodando, que o volume batia bem acima de 100 requisições simultâneas nesse pipeline. Reforça a causa raiz identificada.

Teste ao vivo autorizado, com o Nalberth (suporte IXC) acompanhando em tempo real. Deploy da correção: 14:26 e 14:45 de 01/09/2026 (2ª rodada corrigiu o componente de polling certo — ver nota na seção anterior). Backend reiniciado 2x, 0 erros, 0 restarts inesperados.

Resultado: 0 técnicos genuinamente ociosos nesse período (condição de negócio: última OS do dia em execução) — pipeline pesado não disparou, sem erro. Não comparável ao pico do incidente (que exigia vários técnicos ociosos ao mesmo tempo), então segui pro teste 2.

Técnicos usados (coordenada real de hoje): EDER PEREIRA FONSECA, WELLINGTON ROBNER DA SILVA, WELLINGTHON SILVA BALBINO, JOANITO APARECIDO DE ALMEIDA, CLAYTON CARVALHO MARIANO, MARCELO SOARES DE ARAUJO, ROQUE PAIVA RIBEIRO NETO, TIAGO DE MIRANDA — 8/8 reconhecidos como ociosos pela função real.

{
  "horario": "2026-09-01T17:56:05.615Z",
  "tecnicosForcados": 8,
  "tecnicosReconhecidosComoOciosos": 8,
  "chamadasIxcTotal": 1445,
  "chamadasPorEndpoint": {
    "radpop_radio_cliente_fibra": 1,
    "cliente_contrato": 576,
    "cliente": 749,
    "cliente_condominio": 119
  },
  "concorrenciaMaxima": 4,
  "duracaoMs": 96481
}

0 erros nesse período no log do processo (sem "Too many connections", sem unhandledRejection) — confirmado via journalctl.

Pedido explícito: só diagnosticar. rotaexata.js ficou marcado como risco médio-alto na auditoria original, sem investigação a fundo (tinha 3 timers suspeitos: cliente 60s, frota 60s, ausências 30s). Investigado agora item por item.

• Frota (60s) — _frotaIniciarPolling → _frotaBuscarStatusRota → apiGet('posicoes'/'motoristas'). É a API própria do Rota Exata (rastreamento de veículos, rotaexataBase), não é o IXC. Sem risco pro problema em questão.
• Ausências (30s) — _carregarAusenciasRE → /cgi-bin/ausencias.sh. Endpoint interno do portal, não é o IXC. Sem risco pro problema em questão.
• "Cliente" (60s) — na verdade é o refresh principal (_refreshTimer → _load()), que dispara várias sub-rotinas, algumas das quais tocam IXC (detalhado abaixo). Não existe um timer dedicado a "cliente" nesse arquivo — o único lookup do endpoint cliente é a busca por nome do autocomplete (manual, sob digitação do usuário, já classificado risco baixo na auditoria original).

• Sem guard de reentrância em _load(): ao contrário de _processarAutoSyncJobs (que tem _autoSyncProcessando), _load() não verifica se o ciclo anterior ainda está rodando antes de disparar de novo. Num dia com muita OS manual pendente ou muitos jobs de auto-sync (cada um 300ms), um ciclo pode passar de 60s — o próximo setInterval dispara em cima, dobrando temporariamente as 9 chamadas de _fetchOsIxc e potencialmente rodando 2 correlações/auto-syncs em paralelo.
• Sem coordenação entre usuários/abas: se 3-5 pessoas da operação ficam com a tela do Rota Exata aberta ao mesmo tempo (comum — é o painel mais usado, segundo a auditoria original), cada uma roda seu próprio ciclo de 60s de forma independente e não-sincronizada. Na pior coincidência de timing, os picos de 9 chamadas de cada usuário podem se sobrepor.

Pra comparação: o pico confirmado do incidente Mark3 foi ≥124 requisições simultâneas de um só técnico, numa só chamada, sem nenhum limite. O pior cenário aqui (~45, e só por coincidência de timing entre usuários) é de outra ordem de grandeza — estruturalmente mais parecido com os riscos médios já listados pra suporte-mobile.js/rotaexata-comunicacao.js do que com o Mark3.