You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replays attach errors that happened while the replay was running via errorIds.
This is basically a global event processor that adds the ID of each error event it gets to the errorIds set, which in turn ends up being sent to Sentry.
However, turns out that in reality sometimes this includes IDs of error events that do not actually exist on Sentry, leading to weird behavior.
After some investigation, the most probable cause of this is that some of the error events are sampled away after they have been "consumed" by the replay event processor. Some reasons that could lead to this are:
The deduplication integration removes them
They are dropped due to rate limiting
They are dropped by the host app via a custom beforeSend hook or another global event processor
They are dropped when being sent over the network (e.g. failed HTTP request, ...)
In order to fix (or at least, mostly fix), all but the last of these issues, we should introduce some logic that removes eventIds that have been dropped.
Alternatives that have been investigated
Some other ideas we thought about, but ultimately discarded:
Introduce an afterSend hook: This may not work, as an error could be send at the same time or after a replay was sent.
Introduce some custom hooks for this that are always called: Tricky and expands public API surface noticeably.
Monkey patch beforeSend: Can be done, but potentially tricky, as this is/can be user configured.
Proposed solution
We should monkey patch recordDroppedEvent on the client. This is called when an event is dropped either because of returning null from beforeSend / a global event processor, or when dropped due to rate limiting.
The text was updated successfully, but these errors were encountered:
yeah, def, we also think so. However, as fixing this issue has p0 priority for replay, we'll probably do some "easy" (internal) fix for now, and can then later migrate it to a proper hooks solution!
Replays attach errors that happened while the replay was running via
errorIds
.This is basically a global event processor that adds the ID of each error event it gets to the
errorIds
set, which in turn ends up being sent to Sentry.However, turns out that in reality sometimes this includes IDs of error events that do not actually exist on Sentry, leading to weird behavior.
After some investigation, the most probable cause of this is that some of the error events are sampled away after they have been "consumed" by the replay event processor. Some reasons that could lead to this are:
beforeSend
hook or another global event processorIn order to fix (or at least, mostly fix), all but the last of these issues, we should introduce some logic that removes eventIds that have been dropped.
Alternatives that have been investigated
Some other ideas we thought about, but ultimately discarded:
afterSend
hook: This may not work, as an error could be send at the same time or after a replay was sent.beforeSend
: Can be done, but potentially tricky, as this is/can be user configured.Proposed solution
We should monkey patch
recordDroppedEvent
on the client. This is called when an event is dropped either because of returningnull
frombeforeSend
/ a global event processor, or when dropped due to rate limiting.The text was updated successfully, but these errors were encountered: