#MarkDoesDiscoord
autumn wagon
That's really peculiar. Do you have a repro demo somewhere I can see? Are you able to repro reliably?
buoyant fractal
What would you need for a repro? If we provide a test clock id and user id for each case would that be sufficient? Or would you want our e2e test code? Or log of API calls?
it is pretty reliable, we basically have a "wait period" flag defined now, and tests will pass for weeks with it set to one value (1 hour) and then they will start failing and we will have to switch it to 3 days for a certain amount of time
autumn wagon
Anything you can give me to help make the issue easier to debug would be helpful. Realistically a demo of the behavior somewhere on a sandboxed website would ultimately be the best and most efficient way of finding a resolution.
robust slateBOT
meager bronze
@buoyant fractal can you move those message from main to here please?
Happy to take a look
buoyant fractal
pseudo code:
- create test clock -> initialized to 1601214700 // Sunday, September 27, 2020 1:51:40 PM
- create customer with test clock id
- create subscription for customer with test clock id with monthly renewal
- wait to receive webhooks that say initial invoice was successfully paid, etc.
- update credit card to one that will fail // 4000000000000341
-- we set the default credit card on the customer, the subscription is set to use the customer default - advance the test clock 1 month
- we verify the invoice hasn't finalized the expected webhook haven't fired (invoicePaymentFailed)
- advance another period of time (this is the one that we have to change between 1 and 72 hours)
- verify invoice has been finalized and invoicePaymentFailed has fired
meager bronze
ty
buoyant fractal
I should note, it is currently taking only an hour, which I believe is the proper amount of time, but last Friday we required the 3 day wait
I can write a typescript script if it would help too, but that will take some time
meager bronze
The timing you describe makes me think this is driven by your handling of the invoice.created webhook
Assuming you respond to that successfully, the invoice will default to finalizing after 1 hr
If you failed to respond to that event, the invoice finalization can be delayed up to 72hr
So I would look at your endpoint configured to get invoice.created events and ensure you're responding successfully
buoyant fractal
sounds good, thanks, we'll check the logs
robust slateBOT
buoyant fractal
we think that was our cause, we looked into it and we did have a failing webhook that we deleted between Friday and when it started working. We tried to reproduce now and couldn't but we are guessing if it gets a successful webhook response before it gets a failed response it still finalizes in the first hour? We have multiple webhooks connected to the invoicePaymentFailed event in our test environment. Thanks!