zentrey-dispute-test

[pseudo bloom]

can you give a concrete example I can look at? My guess is you refund before the dispute is created

[balmy surge]

this is the card we are using
4000000000002685

this is the charge_id
ch_3KGoRnEdH9yQ91Km14CqGtMV

your guess would make sense.
i.e. The test runs so fast that the dispute hasn't been created yet so the refund succeeds

it hasn't been a problem in the past

[pseudo bloom]

sure but it was mostly luck that it didn't. The disputes can take some time to be created and you have to account for this in your tests

[balmy surge]

thanks for the feedback. that's helpful.

[pseudo bloom]

Sure, it's strange it only started failing recently. I've used that test card myself for many years and while it often creates the dispute quickly I've sometimes waited 10+ seconds for it to happen

[balmy surge]

very true. I've only been on the project for a few months. Maybe it's been a rare failure that I didn't know about, but it just became a bigger problem.

[pseudo bloom]

gotcha, so yeah switch the test to add a sleep and a retry until the dispute is created. Or hardcode an existing disputed charge id instead

honestly you shouldn't even test this in your test, you should mock our API instead of hitting us repeatedly

[balmy surge]

you are very correct about that. we have all sorts of frequently run 3rd party integration tests. We need to remove all of them (and there is a ticket at the top of the backlog to do so, but it hasn't quite made it into 'todo' .... yet)

🤞