[bop-devel] Business::OnlinePayment 3.00_04 developer release...

[Phil Lobbes]

Hi Ivan,

I downloaded Business::OnlinePayment::AuthorizeNet 3.16 and did a make
test with Business::OnlinePayment 3.00_04 and based on the results of
those tests I found what appears to be another bug related to the
'_pre_submit' changes in 3.x, specifically the "wrapper" in new()
assuming I'm not losing my mind.  See the bottom of this message for the
output of the test run (NOTE, I limit the amount of memory available to
the process otherwise it will run until it consumes all memory available
on my system and then dies).

The bug as I see it is that the code in B::OP::new() will wrap the
subclass submit() method with an anonymous subroutine regardless of
whether or not it has already done this before.

I have checked in a new version of t/bop.t (1.6 -> 1.7).  We didn't have
any test cases for _pre_submit so I added a couple but there's certainly
still room for improvement.  In total, 8 new tests and 1 new "mock"
driver to give us the test scenario we need to reproduce the deep
recursion bug.

I have also checked in a new version of OnlinePayment.pm (1.16 -> 1.17)
which adds a %WrappedSubmitClassMethod as part of the B::OP class data
so we can keep track of subclasses that we have wrapped so that we
hopefully don't wrap the submit more than once.

If there's anything you don't like we can roll back or change, but I
figured this change was better than leaving things as-is.

Phil

_________________________________________________________________

Here's the full output of verbose AuthorizeNet 3.16 tests with B::OP
3.00_04:

$ (ulimit -v 100000; make test TEST_VERBOSE=1)
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(1, 'blib/lib', 'blib/arch')" t/*.t
t/bop............1..1
ok 1 - use Business::OnlinePayment;
ok
t/capture........1..4
ok 1 - use Business::OnlinePayment;
Deep recursion on anonymous subroutine at .../Business-OnlinePayment/Business/OnlinePayment.pm line 97, <TEST_ACCOUNT> line 2.
Deep recursion on subroutine "Business::OnlinePayment::_pre_submit" at .../Business-OnlinePayment/Business/OnlinePayment.pm line 65, <TEST_ACCOUNT> line 2.
ok 2
ok 3
Out of memory!
dubious
        Test returned status 0 (wstat 11, 0xb)
DIED. FAILED test 4
        Failed 1/4 tests, 75.00% okay
t/check..........1..2
ok 1 - use Business::OnlinePayment;
ok 2
ok
t/credit_card....1..2
ok 1 - use Business::OnlinePayment;
ok 2
ok
t/load...........1..1
ok 1 - use Business::OnlinePayment::AuthorizeNet;
ok
Failed Test Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t/capture.t    0    11     4    2  50.00%  4
Failed 1/5 test scripts, 80.00% okay. 1/10 subtests failed, 90.00% okay.
make: *** [test_dynamic] Error 255


Ivan Kohler <ivan at 420.am> wrote:

> Developer release 3.00_04 has been uploaded to CPAN.
> 
> http://search.cpan.org/dist/Business-OnlinePayment/
> 
> If there are no major problems or objections, I'd like to release a 
> proper 3.00 soon.
> 
> The bulk of this release is a bunch of great cleanup work from Phil 
> Lobbes, but I wanted to point out one new feature, especially to 
> module authors: failure statuses.
> 
> From notes_for_module_writers_v3:
> 
>     - If your processor module encounters a setup problem, communication
>       error or other problem that's prevents the card from even being
>       run, you should die (or croak) with a useful error message.  Setting
>       is_success to 0 and returning normally should only be done when the
>       transaction *processing* was sucessful (or at least elicited some sort
>       of result from the gateway), but the transaction itself returned a
>       "normal" decline status of some sort.
>       
>     - (NEW IN 3.00_04) You should set "failure_status" depending on the
>       specific failure result, if (and only if) the failure results from one
>       of the defined statuses:
> 
>       - "expired"
>       - "nsf" (non-sufficient funds / credit limit)
>       - "stolen"
>       - "pickup"
>       - "blacklisted"
>       - "inactive" (inactive card or not authorized for card-not-present) (?)
>       - "decline" (other card/transaction declines only, not other errors)
>   
>       You should use code like this so your module can work with B:OP versions
>       before 3.00_04:
> 
>         $self->build_subs('failure_status') unless $self->can('failure_status');
> 
>       (or add "failure_status" to your build_subs call if you have one during
>       initialization)
> 
> 
> -- 
> _ivan
> _______________________________________________
> bop-devel mailing list
> bop-devel at 420.am
> http://420.am/cgi-bin/mailman/listinfo/bop-devel