Sentry-javascript: O código-fonte não foi encontrado para index.js

Você pode postar um link direto para o evento?

(você também perdeu alguns caminhos na captura de tela do stacktrace que você mascarou anteriormente 😅)

Algum motivo específico para você não usar Sentry.captureException diretamente, mas sim criar seu próprio evento?

Sim, este é o evento: https://sentry.io/share/issue/e2c8d20b66d2406cb32c540d87654b4a/ (ligeiramente modificado para não publicar nosso dsn)

A razão pela qual eu uso Sentry.captureEvent() é a seguinte: Estou mantendo um plugin hapi que captura eventos de erro lançados por manipuladores de rota hapi (enriquecidos com dados de solicitação). Veja: hapi-sentry ./index.js#L41-L67

@guischdi o motivo pelo qual você recebe esse erro é que os caminhos de arquivos locais não podem ser acessados ​​por servidores remotos.
O Sentry está tentando buscar e resolver /something/local/src/app.js e ler o código-fonte dele para fornecer mapeamentos de erro melhores (funciona da mesma maneira com arquivos de mapa de origem).

Para fazer upload de seus arquivos, você pode usar nossa CLI https://docs.sentry.io/cli/ ou plug-in Webpack https://github.com/getsentry/sentry-webpack-plugin

Aqui estão alguns documentos antigos sobre mapas de origem, mas o conceito é o mesmo para o novo SDK https://docs.sentry.io/clients/node/sourcemaps/ (tudo se aplica da mesma maneira ao seu problema atual).

Há também uma integração existente que você pode usar para reescrever caminhos em cada quadro https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/integrations/pluggable/rewriteframes.ts

Assim, por exemplo:

Sentry.init({
  dsn: "https://[email protected]/297378",
  integrations: [new Sentry.Integrations.RewriteFrames()]
});

Mudará /something/local/src/app.js para app:///app.js ( app:/// é nosso prefixo interno), então quando você carregar app.js para seus artefatos de liberação de sentry, ele será lido corretamente sem uma necessidade de buscar arquivos externos.

Basicamente o que você precisa fazer é:

• definir uma chamada release em init
• carregue suas fontes para o mesmo lançamento no Sentinela
• certifique-se de que os frames nos erros que você detecta correspondem aos dos seus arquivos de upload

Espero que esclareça algumas coisas para você. Sinta-se à vontade para perguntar qualquer coisa se precisar de mais ajuda.

Olá @kamilogorek
Obrigado pela sua resposta detalhada.

Acertei: A maneira comum de exibir um rastreamento de pilha de um aplicativo Node.js no Sentry é carregar os arquivos de cada versão via integração RewriteFrames ou manualmente? Se sim, como é que o rastreamento de pilha em captureException /catch-all é mostrado e nenhum erro 'código-fonte não encontrado' é acionado.

Eu testei como lançar um Error em uma node_modules lib funciona. O erro é relatado corretamente, incluindo o código-fonte, mesmo da lib. Veja https://sentry.io/share/issue/2b95ecb13ce24227b2184b2561e4f6e3/

Então, por que isso funciona com captureException e falha com captureEvent ?

@guischdi você pode passar o link completo para os dois eventos? Não compartilháveis? Eu posso acessá-los através de permissões de administrador.

Além disso, estarei fora do escritório pelas próximas 3 semanas, então tentarei voltar a este quando voltar.

@kamilogorek

• este é o link captureEvent
• este é o link captureException

Obrigado por dar uma olhada nisso!

@kamilogorek Você quer dizer que eu preciso fazer o upload da pasta node_modules inteira para cada lançamento também? Por que @sentry/node quando rodando no servidor e tem todas essas fontes disponíveis só não consegue fazer upload dos arquivos necessários com relatório de erros?

Confirmo que depois de definir a integração de quadros e basicamente fazer o upload de node_modules resolve esse problema para mim. Mas o processo de upload de tantos arquivos node_modules é extremamente lento.

Acredito que a solução para isso seja:

1. permitir por sentinela fazer upload de .tar de toda a versão
2. compile o projeto do nó para um único .js e .map e implante e carregue apenas esses dois arquivos.

Além disso, eu estava tendo problemas com mapas de origem que referenciavam o arquivo .ts que não estava no pacote node_modules npm - https://github.com/prisma/graphql-middleware/issues/159

@kamilogorek Alguma novidade sobre este assunto?

Também posso confirmar que reescrever frames foi a solução para nós.

Nosso caso é um pouco diferente, estávamos tentando fazer o sourcemaps funcionar, mas o arquivo minificado sempre foi o usado pelo Sentry. Para a versão correspondente, estamos fazendo upload de arquivos minificados, bem como mapas de origem associados. Parece que o Sentry não estava encontrando o mapa de origem e estava padronizando o arquivo minificado (que ainda está hospedado no mesmo caminho que os mapas de origem).

Acabamos de adicionar new Integrations.RewriteFrames() à chave de integração para o init do Sentry, e os mapas de origem começaram a ser escolhidos para cada novo problema.

É bom saber que a integração RewriteFrames e o upload de node_modules parecem resolver o problema. Mas primeiro (como @mieszko4 já mencionou), carregar tantos arquivos é bastante irritante. E, além disso, minha descoberta inicial foi,

que o rastreamento de pilha em captureException /catch-all é mostrado e nenhum erro 'código-fonte não encontrado' é acionado

Assim, fica em aberto a seguinte questão:

Então, por que isso funciona com captureException e falha com captureEvent ?

Ou mais precisamente: pode-se simplesmente capturar um erro via captureException sem problemas, mas para capturar via captureEvent um upload de todos os arquivos (integração RewriteFrames ou manualmente) para evitar o erro "código fonte não foi encontrado". Isso é um bug ou intencional, @kamilogorek?

@guischdi desculpe por uma resposta tão tardia. Perdi um pouco a pista. Você pode refrescar minha memória o que está acontecendo aqui e fornecer alguns exemplos de eventos?

@kamilogorek
Sim, nosso problema é:

• captureException funciona bem, mesmo se node_module gerar um erro; veja esta exceção de teste
• captureEvent dá uma surra de sentinela: error encountered while processing this event: [...] Source code was not found ; veja este evento de teste

@guischdi apenas para confirmar, este é o arquivo js do nó bruto, certo? sem webpack, sem compilação, sem mapas de origem. Apenas um arquivo index.js com 2 chamadas diferentes em linhas diferentes? Você pode fornecer o conteúdo deste arquivo, se possível?

@kamilogorek
Sim, nodeJS bruto. Dê uma olhada na segunda questão que relacionei acima . Você já vê todas as 13 linhas do index.js lá.

@guischdi estamos investigando por que está se comportando assim (2 frames consecutivos com o mesmo URL acionam isso). Enquanto isso, você pode desativar "Enable JavaScript Source Fetching" nas configurações do seu projeto, por exemplo. https://sentry.io/settings/kamil-ogorek/projects/testing-project/
É um aplicativo de nó, então não faz sentido fazer isso.

@kamilogorek Ok, desativei a configuração "Ativar busca de fonte JavaScript" e acionei outro erro. Mas ainda 1 error encountered while processing this event: [...] Source code was not found (veja esta edição )

Estranho, isso funciona para mim muito bem. De qualquer forma, tentaremos investigar por que isso acontece, embora eu não possa prometer quando isso acontecerá, pois não é um grande problema impedir que nada funcione. Vai mantê-lo informado!

@kamilogorek alguma novidade sobre isso?

Para mim, a exibição do problema relata que o código-fonte está faltando alguns arquivos, mas todos estão presentes e visíveis no rastreamento de pilha.

Estou executando o Sentry auto-hospedado e usando @sentry/node 5.4.3

Segue meu código:

// file: <path>/code/cli
const Sentry = require('@sentry/node');
Sentry.init({ dsn: process.env.SENTRY_DSN });
function test () {
  throw new Error('test');
}
test();

Também estou recebendo este erro:

E aqui está a pilha:

Error: test
  File "<path>/code/cli", line 10, col 9, in test
    throw new Error('test');
  File "<path>/code/cli", line 13, col 1, in Object.<anonymous>
    test();
  File "internal/modules/cjs/loader.js", line 1063, col 30, in Module._compile
  File "internal/modules/cjs/loader.js", line 1103, col 10, in Module._extensions..js
  File "internal/modules/cjs/loader.js", line 914, col 32, in Module.load
  File "internal/modules/cjs/loader.js", line 822, col 14, in Module._load
  File "internal/modules/cjs/loader.js", line 1143, col 12, in Module.runMain
  File "internal/main/run_main_module.js", line 16, col 11, in null.<anonymous>

Também estou enfrentando esse problema Source code was not found

@LukeXF você pode fornecer um link para um evento afetado?

A razão pela qual você pode ver o contexto de origem (ou seja, código acima e abaixo da linha em questão) mesmo recebendo erros "não é possível encontrar o código-fonte" é que no SDK, antes de enviarmos o evento, nós registre essas informações como parte do processamento do rastreamento de pilha . O erro está vindo do servidor _também_ tentando preencher essa informação.

No entanto, isso é um bug do nosso lado, porque não esperamos que você faça o upload de node_modules com cada versão (para aplicativos de nó; para aplicativos de navegador, você provavelmente está agrupando / minificando de qualquer maneira). Deve ser corrigido por https://github.com/getsentry/sentry/pull/17538, que será implantado em algumas horas.

Uma vez que a correção chegar, qualquer um que tenha comentado aqui, por favor, deixe-nos saber se você ainda tem problemas/dúvidas, e quais são eles? Feliz em reabrir isso, se necessário.

Olá @lobsterkatie
testei novamente, com o seguinte trecho (retirado do README atual no npm):

const Sentry = require('@sentry/node');

Sentry.init({ dsn: process.env.DSN });

(async () => {
  Sentry.captureException(new Error('Good bye'));
})();

Infelizmente, ainda recebemos o erro Source code was not found em https://sentry.io/share/issue/0247fe07741c4e358089461f113cef42/
A correção que você introduziu ontem já foi implantada?

Também testado com a versão v4.xx atual (v4.6.6) e a versão mais recente (v5.14.0) de @sentry/node.

@guischdi você não

Por favor, siga os documentos primeiro: https://docs.sentry.io/platforms/node/sourcemaps/

@kamilogorek

no SDK, antes de enviarmos o evento, registramos essas informações como parte do processamento do stacktrace. O erro está vindo do servidor também tentando preencher essa informação.
No entanto, isso é um bug do nosso lado, porque não esperamos que você faça upload de node_modules a cada lançamento

Se eu entendi @lobsterkatie bem nesse ponto (citado acima), não precisaria fazer o upload do código. No link do problema, você pode ver todo o contexto do código-fonte necessário para entender o problema (neste caso, todo o código-fonte do script). Então, isso parece estar registrado corretamente. Eu não acho que preciso fazer upload/servir mapas de origem (como seu link propõe), porque é um programa Node.js simples não minificado.
Acho que o único problema que resta é o erro exibido, embora o contexto seja fornecido corretamente. O servidor parece não reconhecer que não precisa de uploads adicionais do meu lado. (Estou entendendo direito @lobsterkatie ?)

@guischdi O arquivo que está procurando é do seu aplicativo, não de node_modules, então a alteração que fiz (para excluir com mais sucesso o código de terceiros) não se aplicaria aqui.

A razão pela qual tentamos processar mapas de origem para aplicativos de nó é que, embora seja verdade que o código provavelmente não seja minificado, ele poderia ser facilmente transpilado (se fosse escrito em texto datilografado, por exemplo) e, portanto, precisaríamos de fonte maps para exibir o código conforme escrito em vez da saída do babel.

Ok, então isso parece um bug UX para mim. Na minha opinião deve (pelo menos para projetos Node.js) ser apenas um aviso e não deve dizer Source code was not found mas algo como Source maps were not found . Isso teria evitado um problema com um histórico de mais de um ano ;)
Se você quiser, pode reabrir este problema como um relatório para quem trabalha na parte de frontend/display, ou apenas deixá-lo fechado e relatar esse mal-entendido a eles. Muito obrigado por finalmente esclarecer isso!