1. Handler calls repository to associate Google user
2. Repository has business rules, when this happens, we:
3. Associate the user in google_users
4. Create a subscription

This does too many things?

It's impossible to tell based on that description alone. If, for example, each one of those bullet points means ALL of the logic revolving around that down to the IO calls, yeah that's too much.

But your bullet point list here might just be calling other objects to do that work for you. In that case, this method isn't doing too much, because it's doing one thing: orchestrating the flow.

This is the core answer to your question, which is built on a supposition that one can objectively label SRP based on a generalized bullet point description without looking at the concrete implementation. It misses the point of what SRP tries to solve. This is a very common misinterpretation of SRP and it effectively causes you to fight a ghost problem that's not there, but since you believe it to be there, you spent the effort anyway.

It is unclear to me whether you are using "event" here as shorthand to mean "someone else does it", or if you specifically mean events (which get sent to subscribers that aren't known to the originating class at compile time, as opposed to directly calling a method on a known instance).

Events are a way of having two (or more) classes cooperate to achieve a common goal while being loosely coupled; but it's not the only way. With that in mind, let's answer your core question:

Yes, SRP generally suggests that you break down sufficiently independent responsibilities. The knock-on effect to this is that these separate objects now have to interact with one another, and this interaction should be loosely coupled. There are multiple ways to loosely couple this interaction, with events being one of them, but whether you use events or another approach is irrelevant as to how and when you adhere to SRP.

1. Handler calls repository to associate Google user
2. Repository has business rules, when this happens, we:
3. Associate the user in google_users
4. Create a subscription

This does too many things?

It's impossible to tell based on that description alone. If, for example, each one of those bullet points means ALL of the logic revolving around that down to the IO calls, yeah that's too much.

But your bullet point list here might just be calling other objects to do that work for you. In that case, this method isn't doing too much, because it's doing one thing: orchestrating the flow.

This is the core answer to your question, which is built on a supposition that one can objectively label SRP based on a generalized bullet point description without looking at the concrete implementation. It misses the point of what SRP tries to solve. This is a very common misinterpretation of SRP and it effectively causes you to fight a ghost problem that's not there, but since you believe it to be there, you spend the effort anyway.

It is unclear to me whether you are using "event" here as shorthand to mean "someone else does it", or if you specifically mean events (which get sent to any and all subscribers that aren't known to the originating class at compile time, as opposed to directly calling a method on a known instance).

Events are a way of having two (or more) classes cooperate to achieve a common goal while being loosely coupled; but it's not the only way. With that in mind, let's answer your core question:

Yes, SRP generally suggests that you break down sufficiently independent responsibilities. The knock-on effect to this is that these separate objects now have to be orchestrated to correctly interact with one another. This orchestration is an additional separate responsibility. The orchestrated interaction should be loosely coupled. There are multiple ways to loosely couple this interaction, with events being one of them, but whether you use events or another approach is irrelevant as to how and when you adhere to SRP.