#oleg-codaio_api
echo archBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1345093466668924979
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
shy escarp
Looks like a bug in Stripe? The Stripe docs say:
All POST requests accept idempotency keys. Don’t send idempotency keys in GET and DELETE requests because it has no effect. These requests are idempotent by definition.
But clearly this DELETE request (req_LZT7QgIbunyKus) isn't idempotent
nimble gorge
If you pass the same idempotency key as that failed request, you will always get its failed response.
Where did that Invoice Item ID come from? What Invoice?
shy escarp
The request succeeded initially
Here's the successsful request: req_ThS9OmBvGxBUaQ
It's part of invoice in_1QwRjLAegRHrUhUqCNKVmqE7. We have a process that makes adjustments to invoices, and it's supposed to be idempotent. Our server restarted or something and is trying to run through that process again, but now it's getting stuck on this DELETE, which we'd expect to be idempotent
echo archBOT
nimble gorge
Ohhhhhhhhhhhhh duh. 😂
Ok, so the DELETE API call is idempotent by its very nature - you cannot delete an object more than once.
If you try to delete it twice, you will get this exact error, but since it wasn't there to delete that means it had already been deleted.
Also in the case of DELETE requests, you likely don't want to include an idempotency key for this exact reason.
Gotta run but my colleague can help further.
modern valley
@shy escarp let me know if you have any more questions here
shy escarp
Sorry, had to step away
Ok, I'd expect an idempotent request to just succeed with a 200, not throw an error
It seems like what we'd need to do is try the request and if we get a resource_missing error, then we just suppress the error?
That's not really ideal though, because then we don't know if there's a bug where we're creating the wrong delete request in the first place
If throwing resource_missing errors for deleting missing resources is by design, I would it if idempotency keys would work with DELETE requests as well, so I would just get the same response back as I did on the initial DELETE request
modern valley
So those are separate errors. You would want to handle those separately and not suppress them