Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Void holds / transactions that return 500s to ensure they do not double-charge #569

Open
rserna2010 opened this issue Apr 15, 2014 · 10 comments

Comments

@rserna2010
Copy link
Contributor

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

  1. an API call to create a hold results in a 500
  2. then afterwards the hold goes through
    then the hold be voided to ensure a 500 means a hold failed. Thereby preventing accidental double charges.
@steveklabnik
Copy link
Contributor

I am very skeptical about this kind of thing, but wanted to get it here for completeness' sake.

@jkwade
Copy link

jkwade commented Apr 17, 2014

@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.

@mahmoudimus
Copy link
Contributor

@jkwade ok, @remear @cieplak and @rserna2010 can help you there. TOGETHER - they make up Captain Support Team

@jkwade
Copy link

jkwade commented Apr 17, 2014

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?

@steveklabnik
Copy link
Contributor

@jkwade I am skeptical that we can effectively prevent duplicate transactions. That's how the web works.

@mahmoudimus
Copy link
Contributor

@steveklabnik we can do it if we use idempotent request ids

@mahmoudimus
Copy link
Contributor

@steveklabnik instead of issuing a POST, issue a PUT to an appropriate URI

@steveklabnik
Copy link
Contributor

Yes, in theory, that would work.

@mjallday
Copy link
Contributor

@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.

@steveklabnik
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants