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
Some users have some advanced use cases. They'd like to attach frequently changing information to crashes, but they can't add this info to the scope, cause it causes a considerable serialization overhead. Therefore, an idea is to add a C onCrashCallback similar to what we had in one of our first versions of SentryCrash SentryCrashReportWriteCallback.
We don't want to expose the SentryCrashReportWriter, because it is powerful and complex, limits our users on what they can do, and gives our users the possibility to shoot themselves into their feet by messing up the crash report, which we want to avoid. Instead, we want to give our users the flexibility to do whatever they want in this callback. Therefore, the SDK passes the eventID of the crash event when the SDK converts the crash report to a SentryEvent. With that approach our users can store information, add the eventID, and in beforeSend they can look up their information and add it to the crash event. Ideally, we would build a more user-friendly API, but our expectations are that only a subset of power users will use this API and it's not worth investing in that API at the moment. We can always iterate on it later.
The SentryCrash reports currently don't contain the eventID, but instead a reportID. Before we can add the callback with the eventID we need to either change the reportID to a UUID as the eventID of SentryEvents, or we generate a UUID / eventID when crashing, attach it to the SentryCrash report and then use it when creating the SentryEvent.
The SDK calls the callback after writing the crash report to disk and storing the screenshot and view hierarchy so if users mess things up in the callback the SDK can still write the crash report. If users crash in their callback or call non async-signal safe code the side effect will be that signal handlers coming after Sentry might not work correctly. We will add this information to the code docs of the callback.
Description
Some users have some advanced use cases. They'd like to attach frequently changing information to crashes, but they can't add this info to the scope, cause it causes a considerable serialization overhead. Therefore, an idea is to add a C
onCrashCallback
similar to what we had in one of our first versions of SentryCrashSentryCrashReportWriteCallback
.sentry-cocoa/Sources/SentryCrash/Recording/SentryCrashReport.h
Lines 69 to 75 in 96bc46f
sentry-cocoa/Sources/SentryCrash/Recording/SentryCrashReportWriter.h
Lines 246 to 247 in 96bc46f
We don't want to expose the
SentryCrashReportWriter
, because it is powerful and complex, limits our users on what they can do, and gives our users the possibility to shoot themselves into their feet by messing up the crash report, which we want to avoid. Instead, we want to give our users the flexibility to do whatever they want in this callback. Therefore, the SDK passes the eventID of the crash event when the SDK converts the crash report to a SentryEvent. With that approach our users can store information, add the eventID, and inbeforeSend
they can look up their information and add it to the crash event. Ideally, we would build a more user-friendly API, but our expectations are that only a subset of power users will use this API and it's not worth investing in that API at the moment. We can always iterate on it later.The SentryCrash reports currently don't contain the eventID, but instead a reportID. Before we can add the callback with the eventID we need to either change the reportID to a UUID as the eventID of SentryEvents, or we generate a UUID / eventID when crashing, attach it to the SentryCrash report and then use it when creating the SentryEvent.
The SDK calls the callback after writing the crash report to disk and storing the screenshot and view hierarchy so if users mess things up in the callback the SDK can still write the crash report. If users crash in their callback or call non async-signal safe code the side effect will be that signal handlers coming after Sentry might not work correctly. We will add this information to the code docs of the callback.
sentry-cocoa/Sources/SentryCrash/Recording/SentryCrashC.c
Lines 70 to 110 in ab0012c
The text was updated successfully, but these errors were encountered: