Sentry-javascript: 기본 API 캡처* 메서드에서 약속 반환

이것을 강조해 주셔서 감사합니다. 완전히 동기화되지 않았음을 명확히 하기 위해 "전송"이 백그라운드에서 실행 중입니다. 따라서 엄밀히 말해서 이벤트가 Sentry에 도달한다는 보장은 없습니다.

eventId 는 SDK에서 로컬로 생성되며 서버에서 이벤트를 수집하는 데 사용됩니다.

이를 명확히 하기 위해 문서를 업데이트할 것입니다.

자, 명확하게 하기 위해 여기에 설명된 내용을 실제로 구현해야 합니다. https://docs.sentry.io/error-reporting/configuration/draining/?platform=node

맞습니까, @HazAT?

@rhyek Corrent , 모든 것이 전송되었는지 확인하려면 모든 것이 전송되었는지 확인하기 위해 플러시를 기다릴 수 있습니다.

capture* 메소드에서 promise를 노출하는 것이 더 좋지 않을까요? API는 약속을 반환하면 사용자에게 이벤트가 전송되었는지 확인하기 위해 await 해야 함을 알리거나 전송되기를 바라는 것을 잊어버리기 때문에 더 명확합니다. close 와 flush 는 모두 비동기식으로 생각되었던 것을 동기식으로 만들려는 모호한 유틸리티의 메서드입니다. 게다가, 이 두 가지 방법 모두 완전히 망가졌습니다. 사실, 꽤 많은 단점이 있습니다. (나는 그것이 버그라고 말하고 싶지만 아마도 이것은 그것을 보는 사람의 POV에 달려 있습니다):

• 의 목적 timeout 에 전달 flush 그것이 요청의 전송을 방해하여 교통 존중하지 않기 때문에 null입니다. 타이머가 만료되면 반환된 약속을 false 로 해결합니다. 나는 여전히 나 자신에게 그러한 코드와 행동의 유용성을 묻고 있습니다.
• flush 메서드는 호출될 때마다 timeout 에 도달하는 즉시 해결되는 새 약속을 반환합니다. 두 가지 문제가 있습니다. setInterval 의해 실행된 전체 코드는 최소한 브라우저 콘솔의 테스트에서 매우 느리고 제한 시간이 만료된 후 약속이 많은 시간 동안 해결되었습니다. 두 번째이자 더 중요한 문제는 _isClientProcessing 함수의 코드가 호출될 때마다 시간 초과를 지우므로 누군가가 Promise.all([fush(), flush()]) 와 같은 작업을 수행하는 경우(왜 그가 해야 하는지 모르겠습니다. 하지만 API는 그가 하고 싶을 때마다 새로운 약속을 반환하기 때문에 그런 약속은 절대 해결되지 않습니다.

Corrent, 모든 것이 전송되었는지 확인하려면 모든 것이 전송되었는지 확인하기 위해 플러시를 기다릴 수 있습니다.

옳지 않습니다. 플러시를 기다리는 동안에도 모든 것이 전송되었는지 확신할 수 없는 이유를 이해하려면 위의 제 요점을 참조하십시오. 나는 그러한 API 디자인이 완전히 망가졌다고 말하고 싶습니다. 그리고 모두에게 작동할 수 없는 종료 API를 구축하려고 시도하는 대신에 이벤트 전송을 나타내는 약속을 기다리는 선택을 사용자에게 맡기지 않는 이유를 정말로 이해할 수 없습니다. 통합 API가 작동해야 하는 언어

이벤트가 마지막으로 종료될 때 해결되는 약속에 액세스할 수 있다고 생각합니다.
이 스레드에 설명된 다른 방법과 함께 보낸
많은 의미.

2019년 5월 11일 토요일 오후 12:29 Stefano Arlandini [email protected]
썼다:

캡처*에서 약속을 공개하는 것이 좋지 않을까요?
행동 양식? API는 약속을 반환하면 사용자에게
이벤트가 전송되었는지 확인하려면 기다려야 합니다.
전송되기를 바라면서 불을 붙이고 잊어버리십시오. 닫기와 플러시 모두
동기화된 무언가를 만들려고 하는 모호한 유틸리티
비동기식이라고 생각하십시오. 또한 이 두 가지 방법 모두 완전히 깨졌습니다.
사실, 몇 가지 단점이 있습니다(버그라고 말하고 싶지만
아마도 이것은 그들을보고있는 사람의 POV에 달려 있습니다) :

• 플러시로 전달된 타임아웃의 목적은 null이 아니기 때문에 null입니다.
  요청 전송을 중단하여 전송에 의해 존중됩니다. 그것
  타이머가 만료되면 반환된 약속을 false로 해결합니다.
  나는 여전히 나 자신에게 그러한 코드와 행동의 유용성을 묻고 있습니다.
• flush 메소드는 호출될 때마다 새로운 promise를 반환합니다.
  시간 초과에 도달하는 즉시 해결됩니다. 두 가지 문제가 있습니다.
  setInterval에 의해 실행되는 전체 코드는 최소한 다음에서 매우 느립니다.
  브라우저 콘솔에서 내 테스트와 약속은 많은 것을 해결했습니다.
  제한 시간이 만료된 후 초. 두 번째이자 더 중요한 문제는
  _isClientProcessing 함수의 코드가 시간 초과를 지우는 것
  호출될 때마다 누군가가 Promise.all([fush(),
  flush()]) (왜 그가 그렇게 해야 하는지 모르겠지만 API가 반환하기 때문에
  그가 그것을 하려는 유혹을 받을 때마다 새로운 약속) 그러면 그러한 약속은
  절대 해결되지 않습니다.

Corrent, 모든 것이 전송되었는지 확인하려면 플러시를 기다릴 수 있습니다.
모든 것이 전송되었는지 확인합니다.

옳지 않음, 왜 당신을 플러시하는 것을 기다리고 있는지 이해하려면 위의 내 요점을 참조하십시오.
모든 것이 전송되었는지 확인할 수 없습니다. 그런 API 디자인은
완전히 고장 났고 왜 사용자에게 맡기지 않는지 이해할 수 없습니다.
이벤트 전송을 나타내는 약속을 기다리는 선택
모두에게 작동하지 않는 종료 API를 구축하는 대신
통합 API가 작동해야 하는 언어

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
.

또한 결과를 반환하는 메서드가 백그라운드에서 실행될 것으로 기대하지 않습니다. 이것이 사용자에게 혼란의 원인이 되기 때문입니다(물론 이 문제의 주요 질문). 대신, 약속이 반환되면 미래에 올 것이고 아직 준비되지 않은 것에 대한 자리 표시자일 뿐이라는 것이 분명합니다. 그것을 기다릴 것인지 아니면 그냥 불을 붙이고 잊어버릴 것인지 선택은 분명히 사용자에게 달려 있습니다. 또한 이벤트 ID가 로컬에서 생성되기 때문에(btw를 수행할 이유가 없음) 어떤 이유로 전송이 이벤트를 보내지 못했고 사용자가 수행하지 않았기 때문에 유효하지 않은(즉시 반환되기 때문에) 무언가를 사용할 수 있습니다. 그것에 대해 알지도 못한다.

@sentry/node 업그레이드한 이후 Sentry에 상당한 문제가 있었습니다. 더 나은 솔루션이 나올 때까지 raven-node 로 돌아갈 것입니다.

모든 서버리스 실행이 끝날 때 임의의 시간 초과로 대기열을 비워야 하는 것은 확실히 솔루션이 아니라 해킹처럼 느껴집니다. 🤔

작동할 수 있는 더 많은 예를 찾는 사람들을 위해 — #1449 내의 솔루션 중 일부가 플러싱 등에 도움이 된다는 것을 발견했으며 이 문제에 대해서도 많은 논의를 했습니다.

(람다 및 서버리스에 중점을 두고 있지만 플러싱 방식이므로 동일한 개념이 다른 환경에서도 작동할 가능성이 높습니다).

매번 플러싱을 포함하지 않는 더 나은 방법이 있기를 확실히 열망합니다.

이 스레드에서 말한 내용에 완전히 동의합니다. IMO 백그라운드에서 비동기를 숨기는 동기 메서드를 사용하는 것은 정말 혼란스럽습니다.
보초 팀이 이런 식으로 하는 데는 아주 좋은 이유가 있을 수 있습니다. 어쨌든 문서에 대한 업데이트는 정말 감사할 것입니다.

@cibergarri 나는 그 이유가 sentry apis에 대한 잠재적으로 느린 네트워크 호출에서 userland 코드를 차단하지 않고 eventId가 즉시 반환될 수 있기 때문이라고 생각합니다. 비동기 API에서 값을 반환하는 것이 혼란스럽고 비동기 전송 계층 호출에 대해 충분히 오래 머물지 않는 서버리스 실행 컨텍스트에서 오류가 자동으로 손실될 수 있다는 점에 동의합니다. 한 가지 해결책은 함수를 두 개로 분할하여 사용자가 비동기 동작을 선택해야 하도록 하는 것입니다. 예:

Sentry.captureException() // -> returns eventId after successful submission to sentry
Sentry.captureExceptionAsync() // -> returns promise

또는 매개변수로, 예를 들어

Sentry.captureException(ex, {async: false}) // ->  default, returns eventId after successful submission to sentry
Sentry.captureException(ex, {async: true}) // -> returns promise

이벤트 ID는 항상 클라이언트에서 생성되므로 비동기 또는 동기화 API는 중요하지 않으며 결과적으로 이벤트가 실제로 전송되었는지 여부를 나타내는 좋은 지표가 아닙니다(또 다른 문제 imo). 또한 오래 전에 각 capture* 메서드에 대해 동기 및 비동기 메서드를 모두 포함하는 유사한 솔루션을 PHP SDK에 제안했지만 거부되었습니다. 나는 통합 API가 비동기성을 숨기고 싶어하고 개발자들이 약속을 드러내고 싶어하지 않는 진짜 이유를 완전히 이해하지 못했지만, 그들이 이것을 변경하는 데 그다지 개방적이지 않은 것 같았습니다.

슬프게도 이 문제로 인해 서버리스 환경의 추적 오류가 너무 오류가 발생하기 쉽기 때문에 Sentry에서 전환했습니다. (아, 아이러니.)

capture*Async 방법은 매우 유용했을 것입니다 👍

이에 대한 업데이트를 받을 수 있습니까?

@marcospgp 정확히 무엇을 알고 싶습니까? 다니엘이 기록한 모든 것은 오늘날에도 여전히 유효합니다.

나는 문서와는 별도로 사용자가 약속에 액세스하기를 원하는 주석 및 주석 자체에 대한 반응에서 매우 분명하며 이 imho를 허용하지 않을 정당한 이유가 없다고 생각합니다.

불행히도 v6 릴리스 이전에는 발생하지 않을 것입니다. 주요 API에 대한 변경 사항이 있고 많은 변경 사항이 필요하기 때문입니다. 이것을 기록하기 위해 로드맵에 추가하겠습니다.