|Resolved||None||T117466 Q3 GOALS! (January-March) Keep at top of Q3 column|
|Resolved||None||T108229 [Epic] SPOF: Replace ActiveMQ donation queues with a more robust software stack|
|Resolved||None||T133108 [Epic] Rewrite all queue clients to use a single shim library, improve library|
|Resolved||awight||T133754 Upstream whatever we can to PHP-Queue|
|Resolved||awight||T133190 Remove KeyValueStore from PHP-Queue|
|Open||None||T134191 Write CiviCRM extension to view pending db records|
|Resolved||None||T130897 [Epic] Consolidate "pending" queue usages|
|Resolved||awight||T131275 [Epic] Move orphan rectifier out of payments|
|Resolved||awight||T141487 Run the orphan rectifier job from CRM Jenkins|
|Open||Spike||None||T143831 Epic: Reconcile SmashPig and DonationInterface configuration|
You created this as a subtask, so it inherited all tags even those unrelated such as Patch-For-Review or Technical-Debt. Herald can easily remove Patch-For-Review, but can't decide on other tags. Technical debt is obviously the epic parent itself, however, partial tasks to resolve the epic aren't. Cf. Technical-Debt description and https://www.mediawiki.org/wiki/Technical_debt and https://en.wikipedia.org/wiki/Technical_debt. This task is basically about creating new feature.
Still have some request stuff to workaround:
Fatal error: Class undefined: RequestContext in /vagrant/srv/org.wikimedia.civicrm/extensions/DonationInterface/gateway_common/gateway.adapter.php on line 231
One more important detail from code review: we need to run fraud hooks in the orphan rectifier, but not for recurring Ingenico charges. My current theory is that we set up all the fraud hook globals like on payments, but the recurring job somehow avoids calling those. That looks a tiny bit easier and more correct than making a new configuration for the orphan rectifier.
This has been deployed and run one-off, but I haven't convinced myself that we're running fraud checks. In fact, one order which failed CVV on the frontend was happing SET_PAYMENT by the new rectifier. OID 3258119210.
Looks like the glitch is that post_process_get_orderstatus gets called too early, before we've pulled in the CVV and AVS responses. That was a wart anyway--we should go ahead and parse the response as part of normal unstaging.
Note: I was able to run all the fraud filtering with the pending patches applies, but something bad happened with action ranges, a score of 110 still left me with action='process'. To be continued...