Events assigned to wrong project?

SDKs
1

Since v1.1.6 of our app we’ve been sending events to the scoop/ios-prod project. Following a refactor of the logging/event system on our side, we created a new project scoop/ios-prod-stop-the-bleeding and pushed a new version v1.18.0 which sends to the new DSN. Old clients (1.1.6 to 1.18.0) do not have access to this DSN.

However we’re starting to notice events attributed to old releases. For instance 1.13.0, 1.13.1. etc appear in the Releases tab of the new project, even though none of those clients did send to this DSN.

https://sentry.io/scoop/ios-prod-stop-the-bleeding/releases/

image
image.png235×604 16.8 KB

Is there something we’re missing? How come those events are pushed to the wrong project?

2

Hey, did you change something on how we recommend using the SDK?
Because your crash reports mostly also don’t have a full stack trace, mostly only one frame.
Can you also link your other project, please?

3

@HazAT Note that those are not crashes but regular events. We add frames to the event manually – from what I remember Sentry won’t attach a stack trace to those. Also see https://github.com/getsentry/sentry-cocoa/issues/227

Here’s how we add the frame:

let frame = Frame()
frame.fileName = context.file
frame.function = context.function
frame.lineNumber = context.line as NSNumber
event.stacktrace = Stacktrace(frames: [frame], registers: [:])

Here are the two projects (cannot post links for some reason):

  • Old: scoop/ios-prod
  • New: scoop/ios-prod-stop-the-bleeding
4

@ldiqual
Sorry for the late reply, I looked a bit into your projects and I can’t figure out what’s wrong.
I mean your are homebrewing your own events but this can’t be the problem.

The only way I can explain this is:
User of your app runs 1.14.x, app crashes, user does not open the app anymore.
User updates to 1.18.x (a few days/weeks later), event will be sent with the new DSN but with the old version number.
That would explain why “old” version numbers show up in the new project.

There are a few things that we don’t handle ideal in this scenario:

  1. We should actually discard events that are older than a week or so we don’t process them. Since we do a poor job of actually displaying that this event is so old.
  2. We could bind the DSN to the actual event instead of “globally” in the app, but this also has a few drawbacks.

I hope this explains whats going on.

5

@HazAT Thanks for following up on this. I think you have the right explanation here, it makes total sense. Is there a way to access old events when the app starts? We could do some cleanup on our end by deleting events that occurred on version < 1.18.0. Let me know

6

So we did a minor improvement in version 3.10.0 where we hash the DSN and use it as a subfolder.
Since that version if you change your DSN old events will no longer be sent.
Other than that, you could setup an inbound filter under
Settings -> Inbound Filter -> Filter events from these releases

You can enter a regex to discard events of a specific version, be careful 1.14.1 isn’t the full release name, it’s com.takescoop.Scoop-1.14.1 since we prefix the bundle id, so click on a release and check the url to see the full release name.

I hope this helps.
Cheers
Daniel