Page MenuHomePhabricator

Make GlobalCollect recurring processing more robust, handle stale status 600s
Closed, ResolvedPublic2 Estimated Story Points

Description

We currently make the following API calls when making recurring charges in transactionRecurring_Charge,

  1. DO_PAYMENT
  2. GET_ORDERSTATUS
  3. SET_PAYMENT

However, there's a failure at step (1) if we're retrying a transaction which previously aborted before step (3). This happens sometimes.

My suggestion is to move the GET_ORDERSTATUS to before step (1), to detect a pending-poke situation, in which case we will skip the DO_PAYMENT. We can probably omit checking status in step (2), is seems that DO_PAYMENT returns a status code.

Event Timeline

awight claimed this task.
awight raised the priority of this task from to Medium.
awight updated the task description. (Show Details)
awight added subscribers: awight, Aklapper.
awight set Security to None.

Change 233889 had a related patch set uploaded (by Awight):
Skip DO_PAYMENT for already pending charges

https://gerrit.wikimedia.org/r/233889

awight renamed this task from Check GlobalCollect order status to make recurring processing more robust to Make GlobalCollect recurring processing more robust, handle stale status 600s.Aug 27 2015, 12:45 AM
awight edited a custom field.
awight moved this task from Doing to Review on the Fundraising Sprint Rowlf the Dog board.

Change 233889 merged by jenkins-bot:
Recurring charge can settle incomplete transactions

https://gerrit.wikimedia.org/r/233889

I just successfully smoke tested on one of my own subscriptions, seems like the normal charge code path works at least. Keeping this task open until we survive a night of regular batch job. The recurring resume path will be tested as part of T110095.