Sentry-javascript: Livre-se de ignoreErrors

Vou arrancar com 1.1

Tenho muitos erros que ignoro. Por que isso está sendo removido? Por exemplo - eu estava continuamente recebendo um erro que finalmente rastreei ser algum plug-in aleatório do Firefox que gerava um erro espúrio. Não havia nada que eu pudesse fazer sobre isso - então adicionei para ignorarErrors.

@jeremyhaile Você seria capaz de contornar isso com ignoreUrls ? Se não, vou mantê-lo por perto. Tive a impressão de que ninguém usava isso e estava apenas adicionando inchaço. :)

Hmm - boa pergunta. Se eu adicionar um URL como " http://static.ak.facebook.com/ " para ignorarUrls, ele ignora todos os erros provenientes de qualquer diretório / arquivo que comece com esse URL?

ignoreUrls leva uma matriz de padrões de regex. Então você pode fazer o que quiser. :)

@jeremyhaile Especificamente: https://github.com/getsentry/raven-js/blob/master/src/raven.js#L374

OK - vou tentar excluir ignoreErrors de nossa configuração e ver quais erros começo a receber e se ignoreUrls me permite ignorá-los ou não. Eu vou deixar você saber o que eu encontrar.

Sim - já estou encontrando erros que não posso (ou não me importo) consertar e que não podem ser excluídos usando ignoreUrls. Aqui está um erro do IE que já estou recebendo. A correção recomendada de acordo com a Microsoft é "atualizar para o IE8" E a URL está aparecendo como a URL da minha página, que obviamente não quero excluir. http://support.microsoft.com/kb/927917?wa=wsignin1.0

@jeremyhaile Muito justo. Vou mantê-lo por perto. Obrigado por me avisar!

Não tem problema - agradeço as respostas rápidas!

Seria bom se ignoreErrors usasse regexes como ignoreUrls em vez de strings de correspondência exata. Em alguns casos, estou encontrando erros com um código de erro estranho anexado que nem sempre é o mesmo número. Ou erros que contêm a mesma string, mas têm prefixos diferentes em navegadores diferentes.

+1 à sugestão de ignoreErrorPatterns ajudaria a diminuir alguns bits de extensão / ruído injetado por ISP que vejo em nosso site público.

Ruído injetado por ISP

Isso soa bem. : +1:

Sou totalmente a favor de regexes. Você acha que faz sentido essencialmente mesclar essas duas opções em uma que funcione apenas para URLs ou nomes de mensagens?

Ou eles ainda deveriam ser separados?

Eu acho que tê-lo separado seria menos confuso - caso contrário,
parece quase certo que alguém abrirá um problema porque seu regexp
corresponderam mais do que esperavam.

Eu gosto da ideia de renomear para deixar claro que o que você está
fornecer é uma expressão regular ou verificar explicitamente a string vs.
regexp para decidir se deve testar usando == ou .test() para evitar surpresas.

Eu concordo em mantê-lo separado - não consigo pensar em casos em que não estaria explicitamente escrevendo uma regex para o URL em vez da mensagem. Além disso, se estou escrevendo regex de URL, é ineficiente compará-lo com todas as mensagens.

Também gosto da sua ideia de verificar se é uma string ou regex antes de fazer a comparação.

Estou tendo um problema com ignoreErrors (talvez corrigido com regex?), Em que estou recebendo centenas de ""erros no Sentry. Mas meu ignoreErrors está definido como:
ignoreErrors: ['', ......]

No servidor, diz:


9 minutos atrás javascript

Alguma ideia de por que isso não seria filtrado? Deixe-me saber se devo abrir uma edição separada para isso. (e talvez o problema de regex também)

@jeremyhaile Você pode abrir uma edição separada para isso?

Eu reverti este aviso de suspensão de uso. É apenas uma má ideia. :)

Obrigado pela contribuição pessoal!