Call to subscription->create never returns result

[HeartsOfSpace]

Our application calls Recurly PHP library function subscription->create. The call to subscription->create posts the subscription request to the Recurly server, via various functions within the 4.2.1 PHP library. The Recurly server tries to process the request, which fails due to lack of funds. So the Recurly server replies to the caller, a private function in the bowels of Recurly PHP 2.4.1 library, with the code 422. While handling this response the Recurly PHP 2.4.1 library code seems to hang in one of its private library functions called __parseXmlToUpdateObject. The call to subscription->create never returns, and never throws an exception.

There's a coding contract here: subscription->create takes input, and either returns a result or throws an exception. The internal behavior of the Recurly code, and the meaning of 422, should be transparent at the API level. Tracing the 422 reply through the Recurly PHP library code did reveal an apparent bug in __parseXmlToUpdateObject. So now the questions now are why is __parseXmlToUpdateObject hanging, and how can we remedy the problem?

The snippet below is from the Recurly PHP libe file base.php. In the bug we're seeing, the code reaches the line "// add element to existing object...", enters the function __parseXmlToObject, but never returns.

protected function __parseXmlToUpdateObject($xml)
{
$dom = new DOMDocument();
if (empty($xml) || !$dom->loadXML($xml, LIBXML_NOBLANKS)) return null;

$rootNode = $dom->documentElement;

if ($rootNode->nodeName == $this->getNodeName()) {
  // update the current object
  Recurly_Resource::__parseXmlToObject($rootNode->firstChild, $this);
} else if ($rootNode->nodeName == 'errors') {
  // add element to existing object
  Recurly_Resource::__parseXmlToObject($rootNode->firstChild, $this->_errors);
}
$this->updateErrorAttributes();

}

protected static function __parseXmlToObject($node, &$object)
{
while ($node) {

Adding a bit of debug printing just within the while loop at the top of __parseXmlToObject, we see this:

__parseXmlToObject Entry
Node: 1 -- transaction_error
__parseXmlToObject Entry
Node: 1 -- error_code
Node: 1 -- error_category
Node: 1 -- merchant_message
Node: 1 -- customer_message
Node: 1 -- error
Node: 1 -- transaction

Function __parseXmlToObject is recursive, as illustrated by the output above. I wonder if the recursion just never unwinds.

Here is the verbose response to resource.php@ line 86

insufficient_funds soft The card has insufficient funds to cover the cost of the transaction. Your transaction was declined due to insufficient funds in your account. Please use a different card or contact your bank. Your transaction was declined due to insufficient funds in your account. Please use a different card or contact your bank. 2ec865ef041d76349f17b94b86bed7d5 purchase 3900 0 USD declined credit_card 513522801834 subscription false false false false 192.101.136.224 insufficient_funds soft The card has insufficient funds to cover the cost of the transaction. Your transaction was declined due to insufficient funds in your account. Please use a different card or contact your bank. Match Address information unavailable. 2015-05-15T22:03:40Z

100019 hos1@sbrosseau.com S Brosseau 30 Indian Rd San Rafael CA 95476 US Visa 2023 6 494159 3952

[HeartsOfSpace]

Found the problem - our application was not referencing the Recurly table "transaction.php"

Sorted.