Open rserna2010 opened 10 years ago
I am very skeptical about this kind of thing, but wanted to get it here for completeness' sake.
@steveklabnik you're skeptical about the fact that this happened? I'm hearing reports from at least one other MP in addition to the one @rserna2010 mentioned.
@mahmoudimus I'd like to escalate the task of figuring out the scope of the effected transactions to urgent.
@jkwade ok, @remear @cieplak and @rserna2010 can help you there. TOGETHER - they make up Captain Support Team
K, @remear @cieplak @rserna2010: Can I get a report of transactions that occurred during the processor timeout and were returned a 500, so we can being investigating which of them resulted in an actual hold?
@jkwade I am skeptical that we can effectively prevent duplicate transactions. That's how the web works.
@steveklabnik we can do it if we use idempotent request ids
@steveklabnik instead of issuing a POST, issue a PUT to an appropriate URI
Yes, in theory, that would work.
@jkwade I am skeptical that we can effectively prevent duplicate transactions. That's how the web works.
this is not the customer doing a double submission, that we cannot (easily) prevent. this is something internal to the Balanced system retrying a failed request. we should be able to prevent our own systems from doing this.
Okay, @mjallday yes, I agree now. I misunderstood what was originally being asked. A 500 where it actually worked successfully shouldn't be a problem to fix.
Last week a brief timeout issue with the processor resulted in a few cases of the API returning 500s when the holds were actually created.
For instance this request returned a 500: /marketplaces/MP5XOMoofNUnxrzFZxUBZPR6/logs/OHMe1bf6a9ec0d211e395cf06429171ffad
But successfully resulted in the creation of the following hold: /marketplaces/MP5XOMoofNUnxrzFZxUBZPR6/holds/HL7AeslA5E2g9MuA21ssPmvF
It has been requested by a customer that if