Sentry-javascript: 노드 제안: `unhandledRejection`에 오류 기록

좋은 것 같지만 이것이 우리의 debug: true 플래그 뒤에 있어야 하는지 확실하지 않습니다.
결국, 의식적으로 오류 처리기를 연결하여 오류 스트림을 Sentry로 리디렉션합니다.

나도 잘 모르겠다.

Sentry를 활성화하는 것은 포착되지 않은 예외에 대한 로깅을 비활성화하는 효과가 없으므로 처리되지 않은 약속 거부에 대해서도 마찬가지일 것입니다. (비록 이 동작의 차이는 Sentry보다 Node에서 더 불일치합니다.)

Sentry를 활성화하면 내 오류가 보고된다는 것을 이해하지만 특히 dev에서 콘솔 로깅을 별도의 것으로 생각하는 경향이 있습니다. 🤔

우리는 기본 로깅 동작을 수정하지 않으며, 포착되지 않은 예외의 경우 로그 호출을 트리거하는 노드 자체입니다.

여기에서 가장 좋은 해결책은 문서에 메모를 남기고 떠나는 것입니다.

process.on('unhandledRejection', (reason, p) => {
  console.log('Unhandled Rejection at:', p, 'reason:', reason);
});

누군가가 경고를 다시 활성화하려는 경우를 위한 스니펫입니다.

문서로 충분할 것입니다. 적어도 Sentry는 특별한 일을 하지 않습니다. 여기에서 문제는 바로 노드입니다.

완료 https://github.com/getsentry/sentry-docs/pull/785

또는 잡히지 않은 예외는 로그 호출을 트리거하는 노드 자체입니다.

다시 생각해보면 그게 사실인지 잘 모르겠습니다.

Sentry는 기본 노드 동작(log + exit)을 비활성화하는 uncaughtException 핸들러를 등록합니다.

핸들러( defaultOnFatalError )는 자체 로그 호출을 트리거합니다. https://github.com/getsentry/sentry-javascript/blob/4.6.3/packages/node/src/handlers.ts#L282.

포착되지 않은 예외에 대한 로깅을 "복원"하는 경우 처리되지 않은 약속 거부에 대해서도 동일한 작업을 수행해야 한다고 생각합니다.

이것을 다시 열 수 있습니까? 내 마지막 의견에 따르면 이제 Sentry가 잡히지 않은 예외와 마찬가지로 처리되지 않은 약속 거부에 대한 로깅을 복원해야 한다고 생각합니다.

나는 내가 단지 때문에 내 코드에서 실수를했다면 센트리를 사용하고 궁금해하기 시작했기 때문에이 문제를 발견 uncaughtException 내 로그에 있었고,하지 unhandledRejection . 이 두 가지 경우를 같은 방식으로 처리하는 것이 좋습니다.

그래서 나는 둘 다 기록하거나 둘 다 기록하지 않을 것이라고 말할 것입니다.

Node의 코어에서 코드를 복사하는 것보다 이것을 처리하는 더 좋은 방법을 찾았습니다.

λ: node --unhandled-rejections=warn app.js

또한 기본 문서 페이지 https://github.com/getsentry/sentry-docs/pull/1099 에 포함하여 명확하게 만들었습니다.

uncaughtException 와 unhandledRejection 가 다르게 처리되는 것이 여전히 이상합니다. Sentry는 uncaughtException 대한 로깅을 복원합니다. — unhandledRejection 대해 동일한 작업을 수행하지 않는 이유는 무엇입니까? 사용자는 해당 노드 플래그를 사용하는 것을 기억할 필요가 없습니다. 🤔

unhandledRejection에 대해 동일한 작업을 수행하지 않는 이유

하나는 중요하고( unhandledException 는 프로세스를 종료함) 하나는 정보용(따라서 오류가 아니라 경고임)이기 때문입니다.

순서를 반대로 하고 기본적으로 경고를 내보내면 --unhandled-rejections 가 none 로 설정되어 있음에도 불구하고 이를 내보내 CLI 동작을 중단합니다. 현재 공식 노드 문서에 따르면 모든 것이 예상대로 작동합니다. 이 변경으로 인해 비표준이 _됩니다_.

일단 Node가 unhandledRejection 프로세스를 죽이기로 결정하면(현재 4개 버전에 대해 말합니다:P), 공식 사양과도 일치하도록 변경합니다.

순서를 반대로 하고 기본적으로 경고를 내보내면 CLI 동작이 중단됩니다.

@kamilogorek , 하지만 node 실행할 때 unhandledRejection 를 console 합니다. 그래서 나는 공식 노드 문서가 무엇을 말하는지 모르지만 적어도 그것이 내가 알아차린 행동입니다.

unhandledRejection 핸들러를 첨부하지 않은 경우에만 @freeall . 아래 코드를 실행하면 SDK가 없어도 여전히 기록되지 않으므로 실행 중인 코드를 알고 있어야 합니다.

process.on('unhandledRejection', () => `¯\_(ツ)_/¯`);

그리고 우리는 https://docs.sentry.io/platforms/node/default-integrations/를 수행한다는 것을 매우 명확하게 명시합니다.

시스템 통합은 표준 라이브러리 또는 인터프리터 자체에 결합되는 기본적으로 활성화된 통합입니다. 그들이 하는 일과 문제를 일으킬 경우 비활성화될 수 있도록 문서화되어 있습니다.
처리되지 않은 거부
이 통합은 처리되지 않은 전역 거부 처리기를 연결합니다.

노드의 동작을 변경하고 싶지 않습니다. 그게 전부입니다. 그리고 동작은 다음과 같습니다. "리스너가 있으면 방출하지 마십시오. 여전히 경고를 원하면 플래그를 사용하십시오." - 이것이 바로 우리가 하는 일입니다.

@kamilogorek 나는 당신이 어디에서

Sentry가 없는 unhandledRejection 있으면 콘솔에 표시됩니다.
Sentry에 unhandledRejection 가 있는 경우 콘솔에 표시되지 않습니다.

나는 개인적으로 Sentry가 행동을 바꾸는 것을 좋아하지 않습니다.

하지만 이것이 Node.js가 설계된 방식입니다 ¯_(ツ)_/¯
핸들러를 추가하면 경고가 사라집니다. SDK의 주요 목적인 처리되지 않은 오류를 잡을 수 있는 유일한 방법이기 때문에 SDK는 핸들러를 추가합니다.

물론 노드가 어떻게 설계되었는지는 맞습니다. 핸들러를 연결하면 경고가 사라집니다.
사람들이 묻는 것은 노드의 기본 동작을 모방하고 콘솔에 기록하라는 것입니다. 변경된 동작은 Sentry와 같은 도구에서 기대하는 것과 다릅니다.

어쨌든, 당신은 이 동작을 설정한 것 같으므로 토론을 계속하는 것은 의미가 없습니다. 하지만 시간을 내어 답변해 주셔서 감사합니다. :)

@freeall님도 감사합니다 항상 양면 보기 좋네요 :)

명확히 하기 위해: Sentry를 활성화할 때 unhandledException (exit + log)의 동작은 유지되지만 unhandledRejection (log)의 동작은 유지되지 않습니다.

|핸들러|로그|종료|
|-|-|-|
| unhandledException 기본값|예|예|
| unhandledException 보초|예|예|
| unhandledRejection 기본값|예|아니요|
| unhandledRejection 보초|아니요|아니요|

현재 공식 노드 문서에 따르면 모든 것이 예상대로 작동합니다.

여기서 "예상대로"는 사용자가 Sentry가 unhandledRejection 대한 리스너를 등록하고 있다는 것을 이해한다고 가정합니다. 이는 사용자가 걱정할 필요가 없는 구현 세부 사항입니다.

나는 당신의 요점을 봅니다. Sentry는 또한 --unhandled-rejections 준수해야 하며, 플래그가 none 되고 Sentry가 계속 기록하는 경우에는 수행되지 않습니다.

@freeall 주석은 이것을 아주 잘 요약합니다.

Sentry 사용자는 Sentry가 프로그램의 동작을 변경하지 않기를 기대합니다.

포착되지 않은 약속 거부는 "2급 오류"가 아닙니다. 정상적인 오류와 마찬가지로 앱이 중단될 수 있으며 실제로 발생합니다.

여러 사용자(저 포함)가 이 문제에 직면한 것 같으며 앞으로 더 많은 사용자가 이 문제를 겪을 것입니다.

요약하자면 Sentry는 콘솔에서 오류를 차단합니다. 그리고 이것이 얼마나 혼란스러운지 분명하며 아마도 대부분의 보초 사용자가 의도하지 않았을 것이라고 생각합니다. 그들은 콘솔에서 오류의 일부 하위 집합을 침묵시키기 위해 센트리를 설치하지 않습니다.

그래서 추론 ( @kamilogorek 작성 )

이것이 Node.js가 설계된 방식입니다.

나에게 약간 비밀입니다. 이것이 어떻게 보초가 행동해야 하는지를 지시합니까?

사용자가 다음에 대해 알 것으로 기대해야 합니다.

a) sentrys 내부 작동(이벤트 핸들러 등록)

b) 노드 내부 작동(핸들러를 추가하면 경고가 사라짐)

그리고 그들이하지 않는다면, 잘해야합니까?

물론 "글쎄, 사용자는 코드가 내부에서 무엇을 하는지 알아야 한다"는 말은 옳지만 현실은 다르게 보입니다. 그리고 여기에서 보초의 사용 편의성을 높일 수 있습니다.

"우리는 이 문제에 대해 신경 쓰지 않는다"라고 말하는 것은 괜찮지만 "버그가 아니라 기능입니다"라는 식으로 표현하는 것은 불성실해 보입니다.

TLDR: IMOH 사용 편의성을 높이고 초보자 사용자의 문제를 줄이려면 이 문제를 수정해야 합니다.

@OliverJash , @freeall
이 문제에 어떤 솔루션을 사용했습니까?

@schhumannd 로드 방법에서 스니펫을 추가했습니다. 그리고 "버그가 아니라 기능입니다"라는 대답이 만족스럽지 않다는 데 동의합니다. Sentry가 버그를 잡아먹기 때문에 많은 프로그래머가 프로그램에서 버그를 포착하지 못할까봐 두렵습니다. 나에게 Sentry와 같은 도구의 최우선 순위는 버그를 만드는 것이 아니라 잡아내는 것이어야 합니다.

...
if (isUsingSentry) {
  // Log to console because Sentry overwrites standard behavior. https://github.com/getsentry/sentry-javascript/issues/1909.
  // Note that it doesn't overwrite for uncaughtException.
  process.on('unhandledRejection', console.error)
}
...

반응 네이티브에서 센트리를 사용하고 있으므로 이 문제를 해결하기 위해 몇 가지 해킹 작업 을 수행해야 할 것 같습니다. React Native를 사용하고 다른 방식으로 이 문제를 해결하는 사람이 있습니까?

@OliverJAsh , @kamilogorek
이 문제를 다시 열고 수정할 수 있습니까?

Sentry는 콘솔에 오류가 기록되는 방식을 절대 엉망으로 만들어서는 안 됩니다. 이는 브라우저에서도 콘솔 기록이 억제되기 때문에 Node만의 문제가 아닙니다.

디버깅하려고 할 때 매우 성가신 일이며 JavaScript용 문서에서 이것을 언급하지 않았기 때문에 실제로 스테이징 빌드를 테스트하는 동안 콘솔을 볼 때 오류가 없다고 생각했기 때문에 깨닫지 못했습니다. 프로덕션에 배포될 때까지 오류가 발생했습니다. 그것은 오류 보고 서비스에 대한 정말 형편없는 사용자 경험이며, 행복한 고객을 원한다면 수정해야 합니다.

그리고 이전에 말했듯이 약속 거부는 2급 오류가 아닙니다. 다른 처리되지 않은 오류와 마찬가지로 치명적일 수 있으며 어떤 식으로든 억제되어서는 안 됩니다.

따라서 약간의 디버깅을 통해 콘솔 로깅이 억제되는 이유를 알 수 있습니다.

Sentry는 window.onunhandledrejection 함수를 할당하고 여기에서 볼 수 있듯이 해당 함수는 false 반환하므로 콘솔 로깅을 명시적으로 억제합니다. 예, Sentry는 기본 동작을 _does_ 변경합니다. 이는 좋지 않습니다.

운 좋게도 기존 함수에 대한 참조를 저장하고 존재하는 경우 호출합니다.
따라서 콘솔 로깅을 다시 활성화하는 해키 해결 방법은 Sentry를 초기화하기 전에 다음 줄을 추가하는 것입니다.

window.onunhandledrejection = () => true;

이제 이것을 수정하여 무의미한 해킹 없이 기본 동작을 사용할 수 있도록 하십시오 🙂

@schmannd 문제를 다시 열어주세요

@thomas-darling 브라우저 변경에 동의합니다. 약속에 대해서도 true 를 반환해야 하며 변경할 수 있습니다.

그러나 노드의 경우 한 가지 이유로 아직 확신이 서지 않습니다. 코드를 현재 노드 구현에 연결합니다. 플래그에 의존하는 대신 내부를 복사하고 v14에서 약속 거부 동작이 변경되면 현재 있는 노드 버전을 감지하고 그에 따라 조치를 취해야 합니다.
내부적으로 노드는 리스너 배열을 확인하고 리스너가 전혀 없는 경우에만 경고를 내보내고 이 감지를 수정할 수 없으므로 리스너에서 무엇을 반환하는지는 중요하지 않습니다. - https://github.com/nodejs /node/blob/7cf6f9e964aa00772965391c23acda6d71972a9a/lib/internal/process/promises.js#L163 -L216

브라우저 변경과 관련하여 좋은 것 같습니다 :+1:

Node의 경우 Sentry에서 로그인을 수정하지 않으면 기본적으로 모든 사용자가 스스로 하도록 강제합니다. 일부는 잘못하고 일부는 로그인이 필요한지조차 깨닫지 못할 위험이 있습니다. 나처럼 생산 버그에 물렸다. 좋은 개발자 경험이 아닙니다 ...

@thomas-darling 어떻게 수정하시겠습니까? 노드의 코드 안에 있는 동일한 코드를 재현하시겠습니까?

문서 맨 위에는 기본 콘솔 로깅을 얻기 위해 수행해야 하는 작업에 대한 매우 눈에 띄는 메모가 있습니다. https://docs.sentry.io/platforms/node/

노드 동작을 복제해야 하는 것은 잠재적인 유지 관리 문제가 될 수 있으며 노드의 경우 간단한 명령줄 플래그로 해결할 수 있다는 점을 이해합니다.

그러나 노드 동작을 복제하지 않으려면 최소한 해당 플래그가 지정되지 않은 경우 콘솔에 경고를 기록하여 사용자가 오류가 억제되고 있으며 이를 방지하는 방법을 알 수 있도록 하십시오.

이것은 처리되지 않은 거부가 기본적으로 프로세스를 충돌시키는 다음 버전의 노드에서 더욱 중요해집니다. 내가 이해하는 한 Sentry가 핸들러를 추가할 때 발생하지 않습니다.
노드의 새로운 기본 동작에 의존하는 사용자는 치명적인 오류가 발생했음에도 불구하고 나중에 Sentry를 설치하고 프로세스가 갑자기 계속되면 잠재적으로 불쾌한 상황에 처할 수 있습니다.
이는 데이터 손실이나 기타 재해로 이어질 수 있는 종류입니다.

내가 볼 때 몇 가지 옵션이 있습니다.

1. Node.js의 방법 복제
2. 처리되지 않은 거부가 있는 경우 console.error 쓰기
3. 개발자가 볼 수 없도록 오류를 억제하십시오.

1번이나 2번 둘 다 괜찮은 것 같아요. 고객이 오류를 보고 수정할 수 있습니다.
절대 하지 말아야 할 것은 옵션 3입니다. 고객은 오류를 보지 못하고 Sentry는 오류를 생산에 투입합니다(오, 하지만 오류 보고 도구의 아이러니). 이것은 현재 동작이며 실제로 중지되어야 합니다! Sentry는 오류를 더 악화시키는 것이 아니라 오류를 잡는 데 도움을 주어야 합니다.

옵션 2를 선택하더라도 최소한 개발자는 거부를 확인하고 다른 동작(예: 충돌)을 원하고 구현할 수 있습니다. 그러나 거절이 있었다는 사실조차 알지 못한 채, 그들은 그것에 대해 별로 할 수 있는 것이 없습니다.

이 작업을 수행해야 합니다. https://github.com/getsentry/sentry-javascript/pull/2312
아래 코드를 작성하면 똑같은 효과를 낼 수 있으므로 고유한 콜백을 추가하는 방법을 추가하지 않았습니다.

```js
Sentry.init({
통합: [
새로운 Sentry.Integrations.OnUnhandledRejection({
모드: '없음'
})
]
});

process.on('처리되지 않은 거부', (이유) => {
// 콜백
})

나에게 결과는 TypeError: undefined is not a constructor 입니다. 지금 @sentry/react-native 패키지를 사용하고 있기 때문일 수 있습니다. Btw 해당 패키지에 동일한 문제가 있습니까?

@schhumannd @sentry/react-native 는 @sentry/node 를 사용하지 않으므로 이 통합이 없습니다. 이를 위해 sentry/browser를 릴리스한 후 버전을 업데이트하기만 하면 정상적으로 작동합니다(핸들러에서 true 를 반환하는 변경은 기본적이며 구성할 수 없음).

@kamilogorek 잘생김 👍

이렇게 해주셔서 감사합니다! 이 릴리스되면 여기에서 ping할 수 있습니까?

@OliverJash 핑 :)

내가 올바르게 이해했는지 확인하기 위해: Node의 --unhandled-rejections=strict 플래그를 사용하면 Node가 처리되지 않은 거부를 예외로 발생시킨 다음 Sentry가 해당 예외를 가로채서 보고합니까? 그것이 내가 보고 있는 것이라고 생각합니다.

--unhandled-rejections=strict 활성화를 시도했을 때 OnUnhandledRejections 통합이 효과가 없는 것처럼 보였기 때문에 질문합니다. 이벤트 리스너가 호출되지 않았습니다.

이것에 대해 몇 가지 문서를 추가할 수 있다면 좋을 것입니다!

문서 PR은 이미 진행 중입니다 https://github.com/getsentry/sentry-docs/pull/1351/

@OliverJAsh 이 변경 사항은 cli 플래그와 관련이 없습니다. 그 행동은 건드리지 않습니다. 변경된 사항은 OnUnhandledRejection 통합에 cli 플래그처럼 작동하도록 하는 새로운 옵션이 있다는 것입니다.

Sentry.init({
  integrations: [
    new Sentry.Integrations.OnUnhandledRejection({
      mode: 'none'
    })
  ]
});

--unhandled-rejection=none 와 (개념적으로) 동일하고 warn 및 strict 마찬가지입니다.
warn (현재 기본값)를 사용하면 경고 및 오류 자체를 기록하지만 프로세스는 활성 상태로 유지됩니다.
strict 를 사용하면 이벤트를 기록하고 캡처하고 플러시하고(전달될 때까지 대기) 종료 코드 1로 프로세스를 종료합니다.

그것은 의미가 있습니다. 통합이 노드 플래그의 동작을 변경하지 않는다는 것을 이해합니다. 그러나 노드 플래그와 관련하여 Sentry가 (이 통합 외부에서) 어떻게 작동하는지 올바르게 이해하고 있는지 확인할 수 있습니까?

내가 올바르게 이해했는지 확인하기 위해: Node의 --unhandled-rejections=strict 플래그를 사용하면 Node가 처리되지 않은 거부를 예외로 발생시킨 다음 Sentry가 해당 예외를 가로채서 보고합니까? 그것이 내가 보고 있는 것이라고 생각합니다.

@schhumannd 참고로, 오늘 아침에 우리는 @sentry/react-native 1.10.0 [EDIT: whoops, should be 1.1.0 ]를 출시했습니다. 이는 @sentry/browser 의 최신 버전을 사용하도록 종속성을 업데이트합니다(반환 포함 - true -대신- false 위에서 언급한 수정).

@lobsterkatie @sentry/react-native의 최신 릴리스는 1.3.7 인

따라서 1.10.0을 설치하려고 하면 작동하지 않습니다. 해결 방법은 무엇입니까?

@schhumannd @lobsterkatie 는 1.1.0 의미했습니다. 5.9.0 of @sentry/browser 업데이트했을 때와 마찬가지입니다. 로깅 수준을 설정하는 처리기 옵션은 최신 버전의 @sentry/react-native 에서도 잘 작동합니다.