Sentry-javascript: Вернуть обещание из основных методов захвата API*

Спасибо за выделение этого, чтобы было ясно, что это не полностью синхронно, «транспорт» работает в фоновом режиме. Так что, строго говоря, не гарантируется, что событие попадет в Sentry.

eventId генерируется в SDK локально и будет использоваться для приема события на сервере.

Мы обновим наши документы, чтобы прояснить это.

Хорошо, просто чтобы уточнить, действительно необходимо реализовать то, что здесь описано: https://docs.sentry.io/error-reporting/configuration/draining/?platform=node

Это правильно, @HazAT?

@rhyek Коррент, если вы хотите убедиться, что все отправлено, вы можете дождаться сброса, чтобы убедиться, что все отправлено.

Не лучше ли просто показать промис из методов capture* ? API будет более понятным, так как возврат промиса сообщит пользователям, что они должны await убедиться, что событие отправлено, или просто запустить и забыть, надеясь, что оно будет отправлено. И close и flush являются методами неоднозначной полезности, которые пытаются сделать синхронным то, что считалось асинхронным. Кроме того, оба эти метода полностью сломаны: на самом деле есть довольно много причуд (я бы сказал, что это ошибка, но, вероятно, это зависит от точки зрения человека, который на них смотрит):

• цель timeout переданная в flush , недействительна, потому что она не соблюдается транспортом, прерывая отправку запросов. Он просто разрешает возвращенное обещание в false по истечении времени таймера. Я все еще спрашиваю себя о полезности такого кода и поведения...
• метод flush возвращает новое обещание при каждом вызове, которое разрешается, как только достигается timeout . Есть две проблемы: весь код, выполняемый setInterval , очень медленный, по крайней мере, в моих тестах в консоли браузера, и промис разрешается через много секунд после истечения тайм-аута. Вторая и более важная проблема заключается в том, что код функции _isClientProcessing сбрасывает тайм-аут каждый раз при ее вызове, поэтому, если кто-то делает что-то вроде Promise.all([fush(), flush()]) (я не знаю, почему он должен делать это, но поскольку API возвращает новое обещание каждый раз, когда у него может возникнуть соблазн сделать это), то такое обещание никогда не будет разрешено.

Коррент, если вы хотите убедиться, что все отправлено, вы можете дождаться сброса, чтобы убедиться, что все отправлено.

Неверно, см. мои пункты выше, чтобы понять, почему даже ожидая сброса, вы не можете быть уверены, что все отправлено. Я бы сказал, что такой дизайн API полностью сломан, и я не могу понять, почему бы не оставить пользователю выбор ожидания промисов, которые представляют собой отправку события, вместо того, чтобы пытаться создать API отключения, который даже не может работать для всех языки, на которых должен работать Unified API

Я думаю, что имея доступ к обещанию, которое разрешается, когда событие наконец
рассылка в дополнение к другим методам, описанным в этой теме, делает
много смысла.

Сб, 11 мая 2019, 12:29 вечера Стефано Arlandini [email protected]
написал:

Не лучше ли просто выставить обещание из плена*
методы? API будет более понятным, так как возврат обещания позволит пользователям узнать, что
они должны ждать его, чтобы убедиться, что событие отправлено или просто
выстрелил и забыл, надеясь, что он будет отправлен. И close, и flush являются методами
неоднозначная утилита, которая пытается синхронизировать то, что было
подумайте об асинхронности. Кроме того, оба эти метода полностью сломаны: в
на самом деле, есть довольно много причуд (я бы сказал, что это ошибка, но
вероятно, это зависит от POV человека, который на них смотрит):

• цель тайм-аута, переданного для сброса, равна нулю, потому что это не
  уважается транспортом, прерывая отправку запросов. Это
  просто разрешает возвращенное обещание в false, когда таймер истекает.
  Я все еще спрашиваю себя о полезности такого кода и поведения...
• метод flush возвращает новое обещание каждый раз, когда он вызывается
  разрешается, как только истекает тайм-аут. Есть две проблемы:
  весь код, выполняемый setInterval, чрезвычайно медленный, по крайней мере, в
  мои тесты в консоли браузера, и обещание решило много
  секунд после истечения тайм-аута. Второй и более важной проблемой является
  что код функции _isClientProcessing очищает тайм-аут
  каждый раз, когда он вызывается, поэтому, если кто-то делает что-то вроде Promise.all([fush(),
  flush()]) (не знаю, зачем ему это делать, но поскольку API возвращает
  новое обещание каждый раз, когда у него может возникнуть искушение сделать это), то такое обещание будет
  никогда не решить.

Corrent, если вы хотите убедиться, что все отправлено, вы можете дождаться сброса
чтобы убедиться, что все отправлено.

Неверно, см. мои пункты выше, чтобы понять, почему даже ожидание сброса вас
не могу быть уверен, что все отправлено. Я бы сказал, что такой дизайн API
полностью сломан, и я не могу понять, почему бы не оставить пользователю
выбор ожидания промисов, который представляет собой отправку события
вместо того, чтобы пытаться создать API отключения, который даже не может работать для всех
языки, на которых должен работать Unified API

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
.

Я бы также сказал, что я не ожидаю, что метод, возвращающий результат, запустит что-то в фоновом режиме, поскольку это является источником путаницы для пользователей (и, конечно же, главный вопрос этой проблемы). Вместо этого, если обещание возвращается, становится ясно, что это просто заполнитель для чего-то, что придет в будущем и еще не готово. Выбор подождать или просто запустить и забыть, очевидно, остается за пользователем. Кроме того, поскольку идентификатор события генерируется локально (кстати, я не вижу причин делать это), вы можете использовать что-то (потому что оно возвращается немедленно), что недействительно, потому что по какой-то причине транспорт не смог отправить событие, и вы не даже не знаю об этом

После обновления до @sentry/node у Sentry возникли небольшие проблемы, и мы, вероятно, вернемся к raven-node пока не появится лучшее решение.

Необходимость сливать очереди по произвольным тайм-аутам в конце каждого бессерверного выполнения определенно больше похожа на хак, а не на решение. 🤔

Для тех, кто ищет дополнительные примеры того, что может работать — я нашел некоторые решения в # 1449 полезными для промывки и тому подобного, они также обсуждают много этой проблемы.

(Они сосредоточены на лямбда-выражениях и без сервера, но те же концепции, вероятно, будут работать и в других средах, поскольку это подход с очисткой).

Определенно заинтересован в том, чтобы в какой-то момент был лучший способ, который не включал бы промывку каждый раз.

Полностью согласен с тем, что сказано в этой теме, IMO действительно сбивает с толку синхронный метод, который скрывает асинхронность на заднем плане.
Может быть, у команды сентри есть очень веская причина сделать это таким образом, в любом случае обновление документации было бы очень полезно.

@cibergarri Я думаю, причина этого в том, что eventId может быть возвращен немедленно, без блокировки пользовательского кода при потенциально медленном сетевом вызове сторожевого API. Я согласен с тем, что возврат значения из асинхронного 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

Идентификатор события всегда генерируется в клиенте, поэтому асинхронный или синхронизирующий API не имеет значения, и, следовательно, это плохой индикатор того, было ли событие отправлено или нет (еще одна проблема imo). Я также давно предлагал для PHP SDK аналогичное решение, которое включало синхронные и асинхронные методы для каждого метода capture* но оно было отклонено. Я не совсем понял настоящую причину, по которой Unified API хочет скрыть асинхронность, а разработчики не хотят раскрывать обещания, но мне казалось, что они не слишком открыты для изменения этого.

К сожалению, эта проблема заставила меня отказаться от Sentry, так как ошибки отслеживания в бессерверных средах были слишком подвержены ошибкам. (О, ирония.)

Методы capture*Async были бы очень полезны 👍

Можем ли мы получить обновленную информацию об этом?

@marcospgp что бы вы хотели точно знать? Все, что написал Даниил, верно и по сей день.

Я думаю, что помимо документации, из реакции на комментарии и самих комментариев довольно ясно, что пользователи хотели бы иметь доступ к обещаниям, и нет веских причин не разрешать это имхо.

К сожалению, это не произойдет до выпуска версии 6, так как это нарушает наши основные API и требует внесения множества изменений. Я добавлю это в дорожную карту, чтобы отметить это.