ref: Record dropped events in BaseClient
#5017
Conversation
packages/core/src/baseclient.ts
Outdated
| // We want to track each category (error, transaction, session) separately | ||
| // but still keep the distinction between different type of outcomes. | ||
| // We could use nested maps, but it's much easier to read and type this way. | ||
| // A correct type for map-based implementation if we want to go that route | ||
| // would be `Partial<Record<SentryRequestType, Partial<Record<Outcome, number>>>>` | ||
| // With typescript 4.1 we could even use template literal types |
There was a problem hiding this comment.
Probably should mention here that I decided not to change this from the previous implementation: https://cs.github.com/getsentry/sentry-javascript/blob/4e722eb8778e27d7910e96ccb1aac108bcbea146/packages/browser/src/transports/base.ts#L101
size-limit report 📦
|
| } else { | ||
| IS_DEBUG_BUILD && logger.error('Transport disabled'); | ||
| } | ||
| public recordDroppedEvent(reason: EventDropReason, category: DataCategory): void { |
There was a problem hiding this comment.
This should only work if the sendClientReports option is true.
There was a problem hiding this comment.
I think we can get away with recording the events, but only actually sending them when sendClientReports is true. At least that's how I envisioned it with #5018.
I would also find it a tad cleaner from a single-responsibility perspective. Wdyt? I'll let you decide 😄
There was a problem hiding this comment.
I think we can get away with recording the events, but only actually sending them when sendClientReports is true
I was thinking problems with integer overflow or outcomes for long running applications (like a node server), but maybe not that big of a deal with what you showed before.
Builds on #5008 to now track any dropped events on the
BaseClient. Next we can implement the sending of the client reports on the SDK specific clients.Ref: https://getsentry.atlassian.net/browse/WEB-775