#eirik-testclock-events
glad shale
Thanks for the info. I will check in to the example ID and get back to you
glad shale
It looks like the finalize time is pretty much exactly the same as the test clock's frozen time after it was advanced. If you advance it to a time closer to the cycle does it finalize and say then as well?
Or does the invoice not finalize at all until the test clock is advanced three days past the cycle?
snow talon
Advancing to a few hours past the beginning of the new period the invoice appears in draft mode. Advancing further by any amount--even one minute, then causes the invoice to be finalized immediately. Might this just be an artifact of how the test clock system operates?
glad shale
Yes it might be, though in my testing the invoice typically finalizes without a second time advancement happening.
I'll double check that this is still working properly for me. I assume you've waited some amount of time before advancing the test clock again? I thought the invoice would be finalized before the clock becomes ready again but I may be wrong. Will test to confirm.
snow talon
Yes, I usually advance the test clock before running each test. I tried again with a fresh subscription and freshly entered 424242... card; same behavior. Invoice gets finalized only after 72 hours or when test clock is advanced by any amount (e.g. 1 minute) within the window.
Though perhaps this is reasonable simulation behavior when webhooks are registered, as they are in this case, since Stripe's rule is to wait for the invoice.created event to be successfully handled, up to 72 hours.
When the clock is advanced from before the 72-hour window to after the 72-hour window, Stripe hasn't had any chance to check if the webhook was handled, and so it picked the end of the window. (That's my theory at least.)
glad shale
Oh, that might be the issue. Yes if you have a webhook endpoint that is active but not responding with a 200 that will delay the invoice actually finalizing
uneven escarpBOT
snow talon
Well, the webhook endpoint is responding with a 200 correctly, but it seems reasonable to have some "undefined" behavior when the test clock is zoomed past the 72-hour window.
I'm fairly satisfied that this is an issue that only occurs during testing; thanks for your help! (Though happy to test more if helpful to you.)
plucky quiver