I don't quite like this entire pattern of accessing Integration.current + Hub.current + assuming that Hub.current.client then is not none. What if we have a method that returns (integration, hub) or (None, None) if the integration is not configured or hub is none or client is none?

Are you concerned about performance or the potential race condition? I would claim that the race condition is practically irrelevant.

I'm mostly concerned because the thing is nullable and every time I read such code I'm not sure if the programmer validated that it's not none here. Rust broke me to look at nullables in a different way now :) Performance i'm not that much concerned.

Ok, I know what you mean but this instance of nullability in particular should be caught by tests. I don't think adding another layer of indirection is really going to help.

Shouldn't it be chain(global_event_processors, self._event_processors)?

I imagine that every event processor looks like this:

if "key" not in event:
    event["key"] = "bar"

and not like this:

event["key"] = "bar"

In the first example, the first event processor sets "key" and every other event processor skips their logic. So the first processor wins.

In the second example the last processor wins, as its the only one whose value does not get overridden.

The reason is that scopes are applied to the event before event processors are, and data set on the scope should win over data set by integrations.

I wonder if we should apply event processors to the event before we apply scope data.

@mitsuhiko why is this a staticmethod?