SDK internal errors being raised as events in Sentry. #9760
Comments
|
I took a look at the bundled javascript code linked in the Sentry issue (from zendesk). I'm not sure if this is really it but what we can see in the bundled code is that the minified version of async function as(t, e, n) {
if (!t.eventBuffer) return null;
try {
n && "buffer" === t.recordingMode && t.eventBuffer.clear(),
n && (t.eventBuffer.hasCheckout = !0);
var i = (function (t, e) {
try {
if ("function" == typeof e && t.type === xr.Custom) return e(t);
} catch (t) {
return (
("undefined" != typeof __SENTRY_DEBUG__ && !__SENTRY_DEBUG__) ||
_.c.error(
"[Replay] An error occured in the `beforeAddRecordingEvent` callback, skipping the event...",
t,
),
null
);
}
return t;
})(e, t.getOptions().beforeAddRecordingEvent);
return i ? t.eventBuffer.addEvent(i) : void 0; // <-- no await here
} catch (e) {
const n = e && e instanceof $o ? "addEventSizeExceeded" : "addEvent";
("undefined" != typeof __SENTRY_DEBUG__ && !__SENTRY_DEBUG__) ||
_.c.error(e),
await t.stop({ reason: n });
const r = U().getClient();
r && r.recordDroppedEvent("internal_sdk_error", "replay");
}
}any chance that the customer is using some kind of bundling plugin that replaces |
|
Fwiw, I also checked our transpilation output and in both CJS and ESM, we're still |
|
I think it happens in the async _switchToCompressionWorker() {
const { events, hasCheckout } = this._fallback;
const addEventPromises = [];
for (const event of events) {
addEventPromises.push(this._compression.addEvent(event));
}
this._compression.hasCheckout = hasCheckout;
// We switch over to the new buffer immediately - any further events will be added
// after the previously buffered ones
this._used = this._compression;
// Wait for original events to be re-added before resolving
try {
await Promise.all(addEventPromises);
} catch (error) {
(typeof __SENTRY_DEBUG__ === 'undefined' || __SENTRY_DEBUG__) && utils.logger.warn('[Replay] Failed to add events when switching buffers.', error);
}
} |
This code looks correct to me - we are returning a rejecting promise from await Promise.all(addEventPromises);should catch it if any of these promises reject 🤔 If you enable
? |
|
@mydea Sorry, you're actually right, I was in a hurry when I checked this and completly missed the "return" statement for Promise.reject(). I revisited the issue and the part where it fails is still in EventBufferCompressionWorker, here's stacktrace: But this code seems ok as well. Not sure what's the reason. I'll check a transpiled bundle a bit later and tell the results. |
|
@jes490 Looking at the bottom of your stack trace, I can see that this seems to be an older version of the (Replay) SDK. We changed this logic a while ago in #8938. Specifically, the Let us know if this fixes things for you. |
|
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you remove the label "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
|
I am running into this exact issue on v8.3.0. Is the advised workaround to add |
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/react
SDK Version
7.75.0
Framework Version
No response
Link to Sentry event
No response
SDK Setup
Steps to Reproduce
The SDK is reaching the replay buffer limit (source code) when recording session replays. I was not able to reproduce it on my own account.
This is raising an event sent by the SDK to the project configured in the SDK initialisation:
The current workaround for affected users is to filter these events with ignoreErrors:
Originally reported here
Expected Result
The SDK should gracefully drop the event exceeding buffer and not raise an exception captured by the unhandled rejection handler.
Actual Result
An event is sent to the Sentry project as in the screenshot (not adding link due to privacy):
The text was updated successfully, but these errors were encountered: