-
-
Notifications
You must be signed in to change notification settings - Fork 19
fix: cocoa crash handling due to sdkInfo removal in cocoa sdk #68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| event?.sdk = sdk | ||
| event | ||
| dropKotlinCrashEvent(event as NSExceptionSentryEvent?) as SentryEvent? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since beforeSend is based on the lambda result we have to put dropKotlinCrashEvent at the end.
| val item = SentryEnvelopeItem(preparedEvent) | ||
| // TODO: pass traceState when enabling performance monitoring for KMP SDK | ||
| val header = SentryEnvelopeHeader(preparedEvent.eventId, SentrySDK.options?.sdkInfo, null) | ||
| val header = SentryEnvelopeHeader(preparedEvent.eventId, null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
M: why is the sdkInfo removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean that events dont have the SDK info anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's removed because the cocoa sdk deprecated sdkInfo. So SentryEnvelopeHeader does not have a param in the constructor with sdkInfo anymore.
The sdkInfo is still being set in beforeSend with PrivateSentrySDKOnly.setSdkName(sdkName, sdkVersion)
| val causes = mutableSetOf<Throwable>() | ||
| var cause = cause | ||
| while (cause != null && cause !in causes) { | ||
| while (cause != null && causes.add(cause)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this just an optimization? can causes.add return false for some reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup, just a minor optimization - add(...) will return false on elements that are already in a set.
ref: #66