是否内置了对处理竞争条件的支持？

Question

条纹API是否具有处理争用条件的内置支持？

例如，如果订阅是past_due，因此我决定取消它，我如何处理在取消发生之前支付发票的竞争条件？

我可以想到几个这样的竞态条件。有没有标准的方法来预防或处理它们？或者，在进行更改后检查状态并在检测到竞争条件时进行必要的调整是检测它们的唯一方法？

Answer 1

是也不是。在你所描述的情况下，条纹API不会阻止该动作，因为条纹不能确定预期的动作是什么。如果您确实打算在延迟付款后立即取消订阅，该怎么办？

然而，Stripe确实使用了"object lock timeouts"的概念，如果您尝试在同一对象上执行太多操作，则API将返回429错误，这可能会导致您试图防止的竞争条件。

为了尽可能地保护您自己，我会混合使用idempotency keys和webhooks来确保执行的请求始终是预期的。

Answer 2

我对这个问题的解决方案是使用较低级别的支付意图(而不是订阅和发票)，并使用我自己的锁定机制。仍然有一些竞争条件，但它们要少得多，也更容易纠正/预防。主要的缺点是，像自动支付重试这样的内置功能较少。