Sending events to multiple projects at same time issue

[AlexandruSpotMe]

Platform:

• iOS
• tvOS
• MacOS
• watchOS

Swift:

• Yes -> If yes, which version? 4.0
• No

sentry-cocoa installed with:

• CocoaPods
• Carthage
• Manually

Version of sentry-cocoa:
3.x.x

---

I have following issue:

I would like to send specific events to different projects. I have 2 sentry clients and i create events that i only send to one or the other. All the events go on both projects.
If instead of storeEvent I use sendEvent it's all good, but I need storeEvent since the user does not always have internet access

Looking at file manager it seems this was never intended to work. Is this something that might be implemented ?

Steps to reproduce:

• create a sentry client , lets say SentryClient1
• create second sentry client , lets say SentryClient2
• create and event, lets say SentryEvent
• store event on first client. (storeEvent)

Actual result:

• both projects SentryClient1 and SentryClient2 will receive the event

Expected result:

• only SentryClient1 project should receive the event

[HazAT]

@AlexandruSpotMe Hey, I will look into this and you are probably right, there might be a problem with the filemanager not knowing which event to send.
Still, sendEvent will store the event if there is no internet connection so you don't need to do this yourself.

[HazAT]

Ok, so I was thinking about how to tackle this problem.
Probably the solution we will take is, storing the DSN with the event itself and before an event will be sent we try to get the DSN from the event, otherwise fallback to the DSN of the Client itself.
Even though this would work and it's kind of an elegant solution without any need for a migration scenario it still has one major problem.

Regarding crash handling;
Right now we only register one crash handler, no matter how many instances of Clients you create.
That means that if a crash occurs the crash handler (KSCrash in our case) will write it's own report to disk and on the next app start up Sentrys Client tries to convert the report and send an event.
Since we only register one crash event handler (and probably always will) we never can tell which Client is the correct one.

Sooo this problem makes it somewhat unnecessary/invalid to fix it since we never can fully support all scenarios.

If you just want to send generic, non crash events, it works right now, so not sure where to go from here.

[AlexandruSpotMe]

Yes it works for my generic non-crash events , until the send request fails and they get stored, then they will be send to all projects instead of just the desired one - making it essentially not usable unless i do events management on my end. :(

The crash is as you described. They get sent to both clients. Regarding a possible fix here: as you said we only register one crash event handler wouldn't this solve it? Only try to send crash reports once a client registers as a crash handler next time the apps runs ?

I understand if it's too many changes / out of scope. Maybe in a future version ?

[HazAT]

🤔
Interesting idea, so let's say:
Client1 = Client + startCrashHandlerWithError
Client2 = Client

In that case, only Client1 will send crash reports not Client2. Event tough both are able to separately store their events and send them whenever they are ready.

Still, the problem remains that if both Client1 & Client2 start the crash handler (there is only one static crash handler by runtime) it is not deterministic which client will win but that would be something we could document to make it clear.

So yes the solution is to document it properly and implement the rest as I proposed.
@AlexandruSpotMe The change isn't actually that big so I will implement this as soon as I find time for it.

[HazAT]

Hey so here's a quick update on the issue.
I didn't do it yet since it already came to my mind we have the same issue for breadcrumbs since we also store them on the file system (in order to have them over app starts).
So to make it work seamlessly (and as expected) there is more to do than initially thought.
We still want to do it since the behavior now is wrong when storing events.

[HazAT]

Hey @AlexandruSpotMe

Sorry, it took so long, a bug forced us to implement the change we discussed in this ticket.
If you upgrade to 3.10.0 the issue should be gone.
Each instance of SentryClient should have it's own FileStore now.