#phonicuk - Webhook retry
flint burrow
af'noon
also along those lines, if there's a way to know if it was an automatic retry, or user-initiated via the dashboard
thin sierra
Testing a couple things but so far I am not seeing a clear way to identify these.
flint burrow
righto
thin sierra
The event does contain information on the request that triggered it, which I'm trying to investigate
Okay, circling back. In my test account events only the ones that come from the Dashboard have the request.id and request.idempotency_key parameters filled in. You could use that to check where the request originated from.
flint burrow
okay cool, that at least lets me detect that circumstance
thin sierra
As for retries, we do pass a pending_webhooks parameter but I think that applies to all events, not just the one being sent.
flint burrow
Documentation says it applies to all queued up for the given endpoint regardless of the original txn
thin sierra
Right, that's what I thought
flint burrow
so for now I'm assuming that if both stripeEvent.Request.Id and stripeEvent.Request.IdempotencyKey have a non null/empty value then it was a user initiated resend via the dash
thin sierra
Not necessarily a user-initiated resend. It could also be triggered by Dashboard actions (such as creating a Customer)
flint burrow
gotcha, so it's a "Human performed a physical action via the Stripe dashboard which ultimately resulted in this webhook request"
in this case I'm watching for CheckoutSessionCompleted
thin sierra
Yeah and we log the request ID so you can dig through your logs and find exactly which human did what action if you need accountability.
Ah, so that is unlikely to be the result of human manipulation in the Dashboard
flint burrow
basically I'm trying to detect if someone goes into the webhook logs and hits the resend button, even though it might be on a successful event
thin sierra
Ah, so that you don't provision the sale twice I'm guessing?
flint burrow
No actually, we check the invoice ID/intent ID to avoid that - it's because a slightly different behaviour is required if its a human initiated retry
Under normal circumstances, a duplicate webhook request is thrown away entirely if there's already an invoice in our system matching the original payment intent and no action is taken - but if a human hits that I want it to disregard that it's duplicate and perform certain (but not all) actions regardless
Knowing if it's an automatic retry is useful for other reasons, to trigger a kind of "Hey, what happened?" response in the handler.
thin sierra
Okay that makes sense. Let me try some more testing to validate (specific to Checkout)
Okay, sorry to say I am seeing request IDs and idempotency keys in the event I triggered from my test integration.
flint burrow
ah, boo :\
thin sierra
Yeah I don't think there is enough data in the Webhook request itself to identify the parameters you are looking for.
flint burrow
ah, in that case my feedback would be that a way to access that information would be really useful - since that information does seem to exist in your backend, something on the request object to say the attempt number and whether it was a manual resend.
thin sierra
Duly noted. And if you view the events in the Dashboard it does have some information about that. Which suggests the capability exists to provide that data.
I will share that feedback
flint burrow
aye that was part of what prompted me to ask since I figured the data existed somewhere
thin sierra
Yup. We just may need to adjust how the event object is created in order to retrieve that information.
thin sierra
You too 👋