Skip to main content
Você passou pelas primeiras verificações e a razão de rejeição é maxAttempts. Esse é o único valor que realmente significa roteamento.

​
O log nomeia a causa

Cada uma destas é WARN ou ERROR e não precisa de nenhuma flag de debug ligada.
routing.rule.broken é logado uma vez por regra, não uma vez por mensagem, e o contador só reseta quando uma nova tabela de roteamento é publicada.Então depois de corrigir uma regra, observe se a linha reaparece, não se fica ausente. Um log quieto não prova nada. routing_rules_broken em /ops/health é o mesmo fato em número, e é a forma confiável de distinguir “corrigido” de “já reportado”.

​
Duas coisas para descartar antes de editar qualquer regra

Um catch-all perfeito apontando para um fornecedor desconectado não entrega nada e parece exatamente um bug de roteamento.
Responde em palavras: “N vendor(s) configured, none bound — nothing can be sent yet.”
Uma regra referenciando um é pulada inteiramente em vez de carregada com menos condições. Porque descartar condições silenciosamente ampliaria a regra.Procure por Skipping … filter '…' is missing or disabled. Se isso esvaziou a tabela default, a configuração de roteamento inteira é recusada e você está no caso ERROR acima.

​
Por que uma regra não casou

Seis causas, e as duas últimas respondem por a maioria das surpresas:
  • Regras são avaliadas de cima para baixo; uma tabela NORMAL para no primeiro match.
  • O fallback tem que estar no fim. Um catch-all acima de outras regras torna tudo abaixo inalcançável. A página de routing do painel avisa nos dois casos.
  • Nomes de atributos precisam bater com os da referência de routing.
  • Comparações de string são case-sensitive a menos que equalsIgnoreCase seja usado.
  • startsWith compara texto literal. Uma expressão regular escrita nele nunca pode ser verdadeira. Use matches. O painel avisa; um arquivo editado à mão não.
  • Um campo não definido não casa com nenhum operador positivo, exceto isNull. product:equals:premium não casa com uma mensagem sem produto. Mas product:!equals:premium casa.

​
Rastreando uma mensagem

Defina outSms.routing.trace para um único serial de mensagem ou id de conta. Toda regra contra a qual essa mensagem é testada então loga qual condição falhou e o que a mensagem de fato continha:
Vale ao vivo. Defina durante o incidente, limpe depois. Deixado vazio custa uma leitura volatile por regra.
Não recorra a outSms.routing.debug. Ele loga toda regra de toda mensagem e renderiza o objeto inteiro da mensagem para isso. Trinta String.replace encadeados por linha. Então é inviável nas taxas em que perguntas de roteamento realmente são feitas. Só é útil em um gateway ocioso reproduzindo um envio único.

​
Os dois números de fila

​
Relacionados

Como o roteamento funciona

Tabelas, regras e a ordem em que resolvem.

Rejeições do fornecedor

Quando o fornecedor está bound e recusando todo submit.