Saltar para o conteúdo principal
Quando um cliente diz que seus recibos de entrega pararam de chegar, a resposta normalmente já é conhecida pelo gateway e simplesmente não está escrita. smsg.diagnostics decide quanto dela está.
Defina pelo painel de controle: Configuration → Gateway → Diagnostics. Sem SQL, e passa a valer no próximo poll de configuração — sem reinício.

Os três níveis

problems é o nível para rodar. É o que responde uma pergunta de suporte sem que ninguém precise ligar algo primeiro — que é exatamente o problema que ele existe para resolver, porque o momento em que você precisa da evidência é sempre depois que a coisa aconteceu.

Defini-lo não muda nada até você defini-lo

smsg.diagnostics fornece o padrão para as duas configurações abaixo. Ele não as sobrescreve. Assim, um gateway atualizado sem nível definido se comporta exatamente como antes, e um operador que já tinha ajustado message.trace.mode mantém o que escolheu. O painel nomeia qualquer configuração que esteja sobrepondo o nível, porque um nível que parece em vigor enquanto uma chave silenciosamente o supera é o único estado confuso que este arranjo pode produzir.

O que ele deliberadamente não toca

Nenhum nível aqui armazena conteúdo de mensagens.smsg.cdr.body guarda o texto das mensagens dos clientes. print.msgs registra números de telefone, corpos de mensagens e senhas de bind. Ambas são decisões sobre reter dados do cliente, tomadas por operadores em jurisdições que respondem essa pergunta de formas diferentes — não botões para quanto detalhe você quer hoje.Subir um nível de diagnóstico para caçar um recibo nunca deve começar a reter conteúdo de mensagem como efeito colateral, então nenhuma das duas faz parte de smsg.diagnostics. Defina-as por conta própria, deliberadamente, e desligue-as de novo.

O que problems registra

Os eventos caem em cdr_event e aparecem na página de uma mensagem sob Customer exchange: Os endereços de callback são armazenados com a query string removida. Uma dlr-url carrega rotineiramente uma chave de API, e essas linhas são amplamente legíveis, então o endpoint é mantido como esquema, host e caminho e nada mais. Isso não tem configuração nem como contornar.

Ver o que o endpoint deles respondeu

Um código de status diz que o callback falhou. Não diz por quê, e o motivo costuma estar no corpo que o endpoint devolveu — {"error": "unknown template id"} e uma página de login em HTML são duas falhas completamente diferentes que chegam as duas como um 500.
A tabela Troca com o cliente na página de uma mensagem passa então a mostrar uma célula Resposta em cada tentativa de callback, que se expande para os primeiros 500 caracteres da resposta e um conjunto fixo de cabeçalhos: tipo, tamanho e encoding do conteúdo, retry-after, location e x-request-id.
Vem off, e é uma chave separada de smsg.cdr.events de propósito. Registrar que um callback falhou e reter o que o servidor de um cliente escreveu de volta são decisões diferentes, e nenhum nível de diagnóstico liga a segunda por você.Nada fora dessa lista de cabeçalhos é mantido, então um set-cookie ou um authorization que um endpoint devolva não é armazenado — nunca é copiado, para começar.
Sem isso a página diz não capturado em cada tentativa, o que é uma resposta diferente de não disponível: a segunda significa que o gateway é anterior ao recurso e nenhuma configuração vai ajudar. Uma tentativa que mostra sem resposta não recebeu resposta nenhuma para guardar — a requisição foi recusada ou falhou antes de o endpoint responder — e ligar a captura não teria mudado isso.

registered_delivery, e o valor que surpreende as pessoas

Um recibo suprimido é quase sempre isto: 0x02 é o que produz “recebemos alguns recibos mas não outros”. O evento receipt.suppressed imprime o octeto armazenado para que ele possa ser lido em vez de adivinhado.

Aumentando para uma única mensagem

Depois envie a mensagem, leia o log, e volte para problems. verbose registra cada miss de roteamento, resposta de submit e enfileiramento — deixá-lo ligado é volume real de escrita em um gateway em produção.