Durante a análise de uma conversa de teste (pedido da PROSPERAR, realizado na manhã de 23 de abril), o cliente perguntou o prazo de entrega. O assistente respondeu que não havia histórico suficiente para estimar e ofereceu escalar para um atendente — apesar de o produto principal (BAEROLUB L 1 A) ter 117 notas fiscais registradas no SAP no último ano, mais que suficiente para uma boa estimativa.
A resposta não era um bug da lógica de cálculo: era consequência de um problema de infraestrutura — a rotina diária que consolida esses dados nunca havia rodado, e com a tabela de consolidação vazia qualquer consulta retornava "sem histórico".
Estimativa baseada no histórico de pedidos. Não constitui compromisso de entrega — a confirmação oficial será dada após análise do nosso time.
Gostaria de escalar para um de nossos atendentes para que eles possam confirmar o prazo de entrega para você?
O BORDER não calcula o prazo de entrega em tempo real — seria lento demais perguntar ao SAP a cada mensagem do cliente. Em vez disso, uma rotina diária varre todos os pedidos fechados do último ano, calcula quanto tempo cada item costuma levar entre o pedido e a entrega, e guarda esses percentis em uma tabela interna. É essa tabela que o assistente consulta quando alguém pergunta "quando chega?".
Essa rotina é executada por um processo separado (worker), que sobe paralelamente à aplicação principal. Ao investigar por que a tabela estava vazia, identificamos que o processo worker estava em um ciclo de reinício: subia, era reconhecido pela plataforma por apenas 8 segundos, recebia sinal de término e era finalizado — antes de conseguir executar o primeiro cálculo. A cada noite, quando a rotina deveria disparar, o processo simplesmente não estava vivo.
A causa do ciclo: a plataforma de hospedagem (Easypanel) exige que todo serviço responda a um "ping de saúde" via HTTP. O worker é um processo de fundo, não um servidor web, então nunca respondia — e a plataforma interpretava isso como "serviço quebrado", derrubava e reiniciava. Loop infinito.
1. O worker agora responde ao ping de saúde. Foi adicionado ao processo um pequeno endpoint HTTP que responde "ok" em qualquer requisição, usando a mesma infraestrutura interna que já existia (sem dependências externas novas). A plataforma passa a reconhecer o worker como saudável e não o derruba mais. O processo fica vivo continuamente e a rotina diária dispara como esperado.
2. Painel de execução manual no /admin → Jobs. Uma nova aba no painel administrativo lista todas as rotinas de background com:
- Nome e descrição do que a rotina faz
- Horário em que roda automaticamente
- Resultado da última execução (duração, quantos itens foram processados, erros)
- Botão Disparar agora para rodar sob demanda
- Barra de progresso em tempo real durante a execução
Com isso, não é mais necessário esperar a próxima execução agendada quando uma rotina precisa ser refeita (por exemplo, após a adição de novos produtos ou correção em dados do SAP). O painel fica disponível para superadministradores.
Acessando /admin e indo na aba Jobs, o
superadministrador encontra cada rotina com as informações
listadas acima. Para a rotina de prazo de entrega
("Sincronização de prazo de entrega"):
- Agendamento automático: todos os dias às 03:00 UTC (00:00 BRT)
- Primeira execução bem-sucedida após a correção: capturada automaticamente no painel
- Disparo manual disponível a qualquer momento via botão
Outras rotinas que venham a ser adicionadas no futuro (recálculos, exports, consolidações) aparecerão automaticamente no mesmo painel — sem necessidade de nova tela.
Situacao: O assistente respondia "sem histórico
suficiente" a toda pergunta de prazo de entrega, mesmo para
produtos com dezenas ou centenas de notas fiscais registradas.
A causa não era a lógica de cálculo — era a rotina diária que
alimenta a tabela de consolidação estar parada há semanas, por
um conflito entre o modelo de verificação de saúde da
plataforma de hospedagem e a natureza do processo (que não é um
servidor web).
Correcao: Foram duas ações complementares:
(1) o processo worker passou a responder ao ping de saúde via
HTTP, saindo do ciclo de reinício e ficando vivo continuamente
para executar a rotina no horário agendado; (2) foi criado um
painel em /admin → Jobs onde o superadministrador consegue ver
o histórico de execuções, acompanhar progresso em tempo real e
disparar manualmente qualquer rotina quando necessário.
Impacto: Perguntas de prazo de entrega passam
a receber estimativas reais baseadas no histórico do SAP, com
disclaimer de que não é compromisso oficial. Quando um item não
tem histórico suficiente de verdade (por exemplo, lançamento
recente), a resposta "sem histórico" continua sendo dada —
agora com fundamento. A equipe técnica também passa a ter
visibilidade e controle sobre as rotinas de background sem
precisar de acesso ao servidor.