You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
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;
}
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 513522801834The text was updated successfully, but these errors were encountered: