feat(core): Record callback_error client reports for throwing user callbacks - #23903
feat(core): Record callback_error client reports for throwing user callbacks#23903msonnb wants to merge 1 commit into
callback_error client reports for throwing user callbacks#23903Conversation
size-limit report 📦
|
d9e33fd to
dd74588
Compare
…callbacks Events, logs, metrics and root spans dropped because a user callback threw were reported with the same outcome as a legitimate filter (`before_send`, `event_processor`, `sample_rate`). A dedicated `callback_error` reason makes them distinguishable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
dd74588 to
8f068cc
Compare
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 8f068cc. Configure here.
| samplingContext: SamplingContext, | ||
| sampleRand: number, | ||
| ): [sampled: boolean, sampleRate?: number, localSampleRateWasApplied?: boolean] { | ||
| ): SamplingDecision { |
There was a problem hiding this comment.
m: this is API breaking, since sampleSpan is exported. I agree that the object is easier to read though . IIRC, we used the named tuple here for bundle size minimization but this is less readable than the refactor.
Breaking here isn't a big deal though, so we can also do it if the tuple no longer works. But if we do, let's add a note in the migration guide.
| () => processor({ ...event }, hint), | ||
| () => null, | ||
| () => { | ||
| throw CALLBACK_ERROR; |
There was a problem hiding this comment.
m: throwing here and in client.ts made me a bit suspicious because we have to be really careful to also catch our throws. Looks like there's a case in replay where we also call prepareEvent which doesn't try/catch the call. I think this only concerns event processor throws though. This leads to us trying to re-send the replay because we assume a network error. Ultimately, we stop recording.
I think we have two options how to avoid this:
- we try/catch in Replay so that this doesn't happen
- we don't throw at all. Instead, we could directly record an dropped event in
notifyEventProcessorsand distinguish there.
Tbqh: I haven't thought this through end-to-end, so maybe 1 is easier. I don't see us reusing prepareEvent much in the foreseeable future. But happy to let you make the call (also feel free to come up with something else).
Drops caused by a throwing user callback were reported with the same client report reason as a legitimate filter. They now use a new
callback_errorreason so the two are distinguishable.Part of #23755