O motivo da falha de envio chega a quem integra, e o limite do robô passa a limitar
Quando o envio de uma mensagem falha, o motivo passa a chegar no webhook para quem integra pela API — antes só o alerta interno sabia. Um follow-up que falha volta a aparecer como falho e com o motivo — desde a versão 4.17.0.0 ele ficava parado sem registro. As caixas de "Ações no funil" nas configurações do robô voltam a limitar de verdade.
- CorreçãoO motivo da falha de envio chega ao webhook. Quem integra pela API recebia apenas que a mensagem falhou, sem saber por quê — agora o campo de detalhe é preenchido também nas conexões NooviConnect, WAHA e UAZAPI, e não só na API oficial.
- CorreçãoFollow-up que falha volta a aparecer como falho, com o motivo. Desde a 4.17.0.0 uma falha de envio deixava o follow-up parado no estado anterior, sem motivo registrado e sem nova tentativa — o tratamento de erro existia e não chegava a rodar.
- CorreçãoAs caixas de "Ações no funil" nas configurações do robô voltam a limitar. Marcar apenas "mover cards" não impedia o robô de fechar negócio nem de editar: a restrição existia na tela e não valia no servidor.
- NovidadeAs configurações do robô passam a informar quais funis ele alcança e quais ações estão liberadas, para uma integração saber o que pode fazer antes de tentar.
- CorreçãoMensagem de erro de provedor deixa de poder carregar credencial. Se o provedor devolvesse um token no texto do erro, ele podia sair junto no detalhe da falha.
Disponibilidade
Esta versão está publicada no Docker Hub. Ela ainda não foi instalada nos servidores — a atualização de cada instalação é um passo separado. Se você está acompanhando um caso específico, confirme a versão que a sua instalação roda antes de considerar o assunto resolvido.
Falha de envio sem motivo
Quando o envio de uma mensagem pelo WhatsApp falhava, quem acompanha pela API recebia que a mensagem falhou e mais nada. O motivo existia — ficava no registro interno do servidor — mas não chegava ao campo de detalhe que a integração lê.
Isso valia para as conexões NooviConnect, WAHA e UAZAPI. Na API oficial da Meta o motivo já chegava, mas frequentemente era o texto genérico que a própria Meta usa para mandar consultar outro campo — que agora também é lido.
O detalhe passa por limpeza automática antes de sair: credencial, endereço interno, e-mail e telefone são removidos.
Limite do robô que não limitava
Nas configurações do robô existe uma lista de ações no funil — mover card, fechar como ganho, fechar como perdido, criar e editar, criar funis. Marcar apenas algumas deveria restringir o robô àquelas.
Não restringia. Um robô configurado apenas para mover cards continuava fechando negócio e editando. A configuração aparecia na tela e o servidor a ignorava.
Ninguém foi afetado: todos os robôs existentes estão com a lista vazia, que significa "tudo que a permissão concede" — e era exatamente o que acontecia. O problema apareceria para o primeiro cliente que confiasse na restrição.
O robô saber o que pode
As configurações do robô passam a informar quais funis ele alcança e quais ações estão liberadas. Antes uma integração só descobria o próprio limite tentando uma ação e sendo recusada.
Follow-up que falha sem deixar rastro
Quando o envio de um follow-up falhava, ele deveria mudar para "falhou" e guardar o motivo. Em vez disso ficava parado no estado anterior, sem motivo e sem nova tentativa.
A causa está na versão do Rails que entrou na 4.17.0.0: o modo de espera entre as tentativas passou a ser recusado, e a recusa acontecia justamente dentro do trecho que iria registrar a falha. Ou seja, o tratamento de erro existia e nunca chegava a rodar — inclusive as três tentativas prometidas nunca aconteciam.
Vale para quem está em qualquer versão entre a 4.17.0.0 e a 4.17.0.6.