Problemas e agrupamento

1Como o fingerprint é feito

Se o SDK envia um array fingerprint, ele prevalece. Caso contrário, o Blipit faz o hash do tipo da exceção mais os últimos cinco stack frames in-app (nome do arquivo e função). Quando não há frames in-app, usa o tipo da exceção e a mensagem com números, endereços hexadecimais e UUIDs substituídos, para que 'order 4821 not found' e 'order 9 not found' sejam agrupados juntos. Eventos sem exceção são agrupados pela mensagem normalizada.

2Altere o agrupamento com regras

Abra a página do projeto e adicione uma regra de agrupamento. As regras rodam em ordem e a primeira correspondência vence. Uma regra corresponde por tipo da exceção igual a, regex da mensagem, nome do arquivo ou função do stack frame contém, ou tag igual a. Agrupar coloca todos os eventos correspondentes em um único problema; Ignorar descarta o evento antes de ser armazenado. As regras levam até um minuto para serem aplicadas. As regexes são limitadas a 200 caracteres, precisam compilar e não podem usar referências retroativas, lookarounds ou repetições aninhadas como (a+)+.

3Resolver, ignorar, reabrir

Um problema está não resolvido, resolvido ou ignorado. Resolva-o quando publicar uma correção: se o erro voltar, o problema reabre como regressão e você é alertado. O problema diz se ele voltou na mesma release (a correção nunca foi publicada) ou em uma posterior (algo o reintroduziu). Ignorar continua contando eventos, mas para os alertas. Reabrir o coloca de volta em não resolvido. A lista de Problemas tem ações em massa, e os e-mails de alerta trazem links de Resolver e Ignorar que pedem confirmação e funcionam uma única vez.

4Silenciar

Na página do problema, silencie por 1 hora, 24 horas, 7 dias ou pelas próximas 100 ou 1.000 ocorrências. Os eventos continuam sendo registrados e contados; os alertas de novo problema e regressão são pulados até o silenciamento terminar. Os alertas de segurança não são afetados.

Bom saber

• O Blipit guarda o payload completo do primeiro evento de um problema, de cada regressão, de cada evento de segurança e dos primeiros 20 eventos de cada hora UTC. Os demais eventos armazenam um resumo (id, hora, plataforma, nível, release, ambiente, tags, id do usuário, SDK). A página do problema diz 'Mostrando detalhes completos de N de M eventos'; o stack trace, os breadcrumbs e a correção com IA leem o payload completo mais recente.
• Depois do teto mensal de eventos do seu plano, 1 evento a cada 10 é mantido e o restante é contado como amostrado; nada é cobrado. A página de Uso mostra a contagem de amostrados.
• Os alertas têm um orçamento de 30 alertas de novo problema ou regressão por projeto por hora, então uma tempestade de erros não consegue inundar sua caixa de entrada.