#windlepoons-events

1 messages · Page 1 of 1 (latest)

final imp
#

One action can certainly set off multiple events depending on what it touches. Not immediately sure on the Invoice example. I can see if we find a doc but if you test it will definitely show the proper behavior

void kettle
#

I'm mainly looking to accurately reflect current Stripe state in our cache (to avoid Stripe API limits). And I want to make sure I'm listening for the correct minimal amount of events to keep invoice/subscription/customer up to date.

#

If the parent event for a bunch of invoice changes is invoice.updated, such that its the only one I need to listen for... I'd prefer to listen just for that one instead of push more changes into our cache that aren't needed.

final imp
#

I see what you are saying. So for here you want to know about how to figure this out in general or are you specifically asking about the paid situation?

void kettle
#

In general

final imp
#

That would be more of a case-by-case basis I would think.

#

So in this case you do actually get paid and updated.

void kettle
#

Does invoice.upcoming also trigger invoice.updated?

#

It'd be great if there was an event hierarchy diagram or something that made it more clear what triggers what, and what 'parent' events will be triggered by more specific things.

final imp
#

Not a diagram but pretty comrehensive

void kettle
#

It misses a lot of detail though

#

An invoice.paid event is sent, indicating that the invoice was successfully paid.

#

It doesn't mention it also sends invoice.updated

#

Nor is there a list of what other invoice events will also trigger invoice.updated. I assume any attribute change on the invoice trigger invoice.updated, but its a little odd to have to try and reverse engineer Stripe to know for sure, and that seems like a brittle implementation detail if it isn't documented behavior.

final imp
#

Yeah I see what you mean. I guess that doc is more for the canonical events you should look at in each of those cases. Is there a reason you are trying to reduce the number of event types you are listening for? The differentiated event types can be very helpful

void kettle
#

Mainly to try and avoid writing the new object to our cache more times than needed.