#windle-events-apiversion

1 messages · Page 1 of 1 (latest)

oak fossil
#

hello, yes I think that is expected, mind sharing that customer.updated event, I can tell you why

light mauve
#

I can see why, the first subscription triggers the currency update on the customer updated.

#

I was more frustrated that I was previously told only the object being changed has the request ID of the API call changing it.

oak fossil
#

only the object being changed has the request ID of the API call changing it.
so maybe it was a miscommunication but it would be multiple objects
e.g. Subscription creation's first Invoice creation (when no trial) would also have a request ID belonging to the Sub creation, eventhough an Invoice object is not what you created, you created a Sub object

light mauve
#

Is there any way when making an API call, to get a list of all changed objects as a result of it?

#

The main issue I'm trying to deal with is cache consistency. I had previously hoped that I could put the updated objects directly in our cache, then ignore the webhook events with a request id as long as I always update the cache myself. That seems problematic though since other objects can update in response to the call.

#

The objects have no version numbers or way I can otherwise determine when getting a webhook, whether the copy I have is newer or older.

oak fossil
#

Is there any way when making an API call, to get a list of all changed objects as a result of it?
afaik there is not, no. But typically you only need to listen to a subset of events and not all events.

whether the copy I have is newer or older.
yeah I wouldn't use webhook events to store all object states and webhooks do not guarantee ordering so you can get a payment_intent.created event after a payment_intent.payment_succeeded event technically

so what I would do is, fetch the object from the API and that gives you the "real" state of the object. And not always re-fetch the object i.e. if you get a payment_intent.created event and you fetch it from the API and the PaymentIntent has status: succeeded, then when the next second you get a payment_intent.succeeded event, you don't need to refetch the PaymentIntent as you know it has succeeded and can ignore further PaymentIntent events for the same PaymentIntent (again, assuming the status is a terminal end state i.e.)

light mauve
#

The Firebase Extension for Stripe updates the database based on objects from the webhook itself, it does not do API calls. Wouldn't this run into problems if Stripe is delivering webhooks out of order? It would insert an older object?

#

Is there some subtly there I'm missing?

oak fossil
#

Wouldn't this run into problems if Stripe is delivering webhooks out of order?
yes that does seem to just be adding Invoice records regardless of webhook ordering and not fetching, you're right

so that extension hasn't taken that into account, so they aren't storing the "true" state of the objects, just as they come in from webhooks

light mauve
#

Since Stripe has API limits and recommends users cache objects, it'd be really useful if there was a more detailed or correct way documented on how/when to store objects, how/when to update them, etc.

#

I was assuming that the Stripe built extension was doing things the 'correct' way.

#

Ideally an entire section of the Stripe developer documentation would cover this.

topaz drift
#

Hello! Taking over and getting caught up, hang on...

#

So your goal is to have a cache of various Stripe objects stored locally on your end, and keep them up to date with webhooks?

light mauve
#

Yes, mainly because we run into API limits with Stripe otherwise under load.

#

My current presumption on handling this in an API call restrictive way, is that I am ok inserting the object from the webhook into my cache, if the object is in a terminal state.

topaz drift
#

Which specific limits do you run into?

light mauve
#

If it is not a terminal state, fetch it via API first, then insert that. Which would account for webhook duplicates or out-of-order issues.

#

We send invoice emails ourselves, this means that when we bump into large renewal periods, we end up hitting Stripe a lot to get all the data needed for our invoice email. (Customer, subscription, invoice, and payment method data).

#

I was hoping to cache these farther in advance so that wouldn't be a problem. I do know the 'proper' solution per other Stripe dev chats is to queue those emails so we can distribute them across time better to avoid this. But putting a queue into the mix was a bigger development task.

topaz drift
#

I see. Yeah, a queue would be the best solution.

light mauve
#

Does the caching strategy I mentioned above sound correct?

topaz drift
#

For the webhooks issue, it's fairly common for people to fetch the current version of the object from Stripe when a webhook is received to ensure they're getting the current version of the object(s) in question.

light mauve
#

Ah, that's good to know. I hadn't seen that mentioned anywhere before.

#

If its a terminal state, that shouldn't be needed?

topaz drift
#

What do you mean by terminal state exactly? Like a Payment Intent that's succeeded?

light mauve
#

subscription state goes to incomplete_expired or cancelled

#

or could those still be updated somehow?

topaz drift
#

The metadata could be updated, yeah.

light mauve
#

Ah, ok, thanks. I'll fetch from Stripe every time then.

#

The Stripe extensions for firestore might need to be re-visited to make sure they're not inserting the webhook objects.