Skip to main content
Uma mensagem pode atravessar o gateway de quatro formas. São caminhos de código genuinamente diferentes e falham de formas diferentes, então conseguir dirigir cada um por conta própria é o que transforma “algo está errado” em uma bisseção.

​
Preparando uma lane

Isso cria uma conta com crédito, um produto com whitelisting desligado, um login SMPP e um login HTTP, uma tarifa plana, e as regras de roteamento que as quatro direções precisam. É idempotente, e um script de teardown correspondente remove exatamente o que adicionou.
Troque as duas senhas antes de apontar para isso qualquer coisa que não seja sua própria máquina.

​
Leia a ordem de match antes de enviar qualquer coisa

O router toma a primeira regra que casa, e a última regra casa com tudo. Duas coisas seguem, e ambas já morderam um deployment real:
Um delivery receipt para uma mensagem cujo remetente era um endereço indiano numérico chega com aquele número em to, uma vez que flag.reverseDlrSrcDst tenha trocado source e destination.Colocada abaixo de uma regra to matches ^91…, esse receipt vai para um fornecedor em vez de para o cliente.Por isso o seed move as regras de destino para baixo em vez de simplesmente encaixar uma regra de classe acima do catch-all.
Ele cai no catch-all, chega ao worker de fornecedor, e é submetido upstream como uma nova mensagem de saída.conf/routingTable.conf sempre carregou essa regra. O banco não — e em modo de banco o banco vence.
Ambas as falhas são silenciosas do lado do cliente: na primeira o receipt simplesmente nunca chega, na segunda ele chega a uma operadora como tráfego pelo qual você paga. Nenhuma produz um erro em lugar algum.

​
O que cada direção prova

1

Direção 1 primeiro — MT out via SMPP

Se isto falhar, nada mais vai funcionar também. Cobre o caminho mais longo.
2

Direção 2 — o ingress REST

Falhar aqui enquanto 1 funciona isola o problema ao ingress HTTP: auth, parsing, rate limits.
3

Direção 3 — receipts de volta

A mais frequentemente quebrada por ordem de roteamento do que pelo próprio caminho de receipt.
4

Direção 4 — MO in

Precisa que o número de destino esteja mapeado a uma conta. Uma mensagem não mapeada é registrada e entregue a lugar nenhum, sem nada observável do lado do cliente.

​
Lendo o resultado

Não julgue uma lane pelo fato do send ter retornado 200 — isso apenas significa aceito para roteamento. Cheque:
  • cdr_submit para uma linha, e cdr_final para um outcome
  • cdr_rejected para qualquer coisa recusada, com seu motivo
  • /ops/health para submitted se movendo no fornecedor
  • O log para message.accepted, message.submitted, message.dlr

​
Relacionado

Throughput

Um baseline medido para comparar contra uma execução de carga.

First checks

Quando uma lane não funciona.