How to get event_id from crash report

[georges]

Platform:

• iOS
• tvOS
• [x ] MacOS
• watchOS

Swift:

• Yes -> If yes, which version?
• [x ] No

sentry-cocoa installed with:

• [x ] CocoaPods
• Carthage
• Manually

Version of sentry-cocoa:
5.2.2

---

I have following issue:

I'm trying to send a user feedback via API after a crash (https://docs.sentry.io/api/projects/post-project-user-reports/).

On next launch I can detect that the application has crashed by looking at crashLastLaunch property on SentryCrash and retrieve the reportIDs. But the user report API needs an event_id to tie the feedback to the crash. How do I retrieve the event_id from the reports?

[philipphofmann]

Hi, @georges. We recently added crashedLastRun to SentrySDK. So you don't have to call SentryCrash anymore.

Unfortunately, we don't have a straightforward way to do this right now. The reports are from our internal crash reporting framework, which originates from https://github.com/kstenerud/KSCrash. We convert the reports to SentryEvents with SentryCrashReportConverter and SentryCrashReportSink passes the event to SentrySDK. You could hook into beforeSend and check if the level of the event was fatal and if crashedLastRun is true. In theory, there could be other events with fatal, so you should make sure you only execute this code once. Our SDK only creates fatal events, if your application crashed.

[bruno-garcia]

@philipphofmann can we add a field called lastEventId (for example, in C#) to SentrySDK and set this value when running the report conversion in SentryCrashReportConverter? That'd mean once Sentry inits, the user would be able to:

if Sentry.crashedLastRun then openUserFeedback(Sentry.LastEventId)

[bruno-garcia]

Also please note that we plan to implement user-feedback in the SDK in Q4.
We're still considering which API to add.

@georges what kind of API would you expect?

Would a callback to be registered during Sentry SDK init suffice? The callback would be triggered passing the event id as suggested above.

[georges]

A callback would be great but the method you described in first post works too. Basically all that is needed is to know if a crash occurred and retrieve the event_id that can be used to post to the user feedback endpoint.

[philipphofmann]

@philipphofmann can we add a field called lastEventId (for example, in C#) to SentrySDK and set this value when running the report conversion in SentryCrashReportConverter? That'd mean once Sentry inits, the user would be able to:

if Sentry.crashedLastRun then openUserFeedback(Sentry.LastEventId)

Yep we can do that. I add it to our Backlog.

[philipphofmann]

Hey @georges, we merged yesterday an API to manually send user feedback to Sentry #805. Now we are working on adding a callback to retrieve the eventId from a crash event in #808. The API would look like this

SentrySDK.start { options in
    // ...
    
    options.onCrashedLastRun = { eventId in
        self.displayUserFeedback(eventId: eventId)
    }
}

// Not a sentry function. Only wraps call to user feedback
func displayUserFeedback(eventId: SentryId) {
		
    // Display UI and get feedback from the user. 

    // Then send feedback to Sentry
    let feedback = SentryUserFeedback(eventId: eventId)
    feedback.comments = "It broke"
    feedback.name = "John Smith"
    feedback.email = "[email protected]"
    SentrySDK.capture(feedback: feedback)
}

Would you be so kind to give us feedback on this one?

[georges]

That design works well. One consideration (I don't know if that's even possible to happen) is wether there can be more than one crash event pending? From what I understand Sentry waits to send crash report on next launch. What if there are two crashes that happened before the app is in a state where Sentry sdk can run again? Would there ever be more than one event? In which case there would be more than one dialog prompting the user which would be odd.

[philipphofmann]

That's a very good point @georges, there could be more than one crash report. What would you expect in such a case?

[georges]

Ok. In case of multiple consecutive crashes, it's very unlikely that the user would know to provide distinct feedback for each situation that caused a crash. So perhaps have the callback fire once but allow for multiple enventId to be passed as an array?

This way the app could decide to display a dialog only once but send multiple capture with same comments for each eventId or only capture and send feedback for the last eventId in the array or prompt the user for every single one if desired.

[georges]

Pulled tag 6.0.10 and tried the feature in my macOS app. Works great. Thank you @philipphofmann 🙏

One small observation is that i was having problems initializing the onCrashedLastRun when I used the dictionary initializer with startWithOptions (well it initialize fine but it crashed when it tried to invoke the callback). I switched to startWithOptionsObject and it worked fine. Note that I'm using RubyMotion, so it's entirely possible that there is some funkiness going when setting the callback in the value/pair dictionary vs. assigning directly to a property. Nevertheless, thought you should know in case you want to try to replicate using startWithOptions in Objective-C with a dictionary.

[philipphofmann]

Thanks for the update @georges. The following code works for me:

SentryOnCrashedLastRunCallback callback = ^void(SentryEvent * _Nonnull event) {
    // ...
};

[SentrySDK startWithOptions:@{
    @"dsn": @"__DSN__",
    @"onCrashedLastRun": callback
}];

Which error do you get?

[georges]

What I got looked like an invalid pointer was being called and crashed the calling thread at execution, which lead me to suspect that the callback assignment was not done properly in my setup. Once I switched to using properties it worked fine. Probably something to do with how RubyMotion translates lambda block to be used as callback and maybe that pointer math is not working well on a dictionary or perhaps not retained in memory or something like that. Probably can just ignore this then. Just wanted to mention it in case there was something affecting Objective C for some odd reason.

[philipphofmann]

Thanks for the detailed update @georges. It's better that to raise a flag when things are uncertain than never raising it.