HTTP::Response may have a different definition of success than you do

This has bitten me before, so I thought it was worth writing about. This RT ticket explains it better than I can, but let me sum things up here.

Consider this code:

use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my $response = LWP::UserAgent->get('http://example.com/foobar');

if ( $response->is_success ) {
   ...
}

99 times out of 100, this will do what you mean. Occasionally it doesn’t.

What is the definition of success? In this case it means that there’s an HTTP response code in the 200s.

Q: What happens if you’ve gotten a 200 response code in the server headers but (for example) there’s a problem with the response body?

A: is_success still returns true.

is_success gives you a technically correct answer, but in this case technically correct isn’t always helpful because something else may have genuinely gone wrong.

Consider what happens in this case where HTML::HeadParser is not installed.

If you want to check for success with confidence, you may want to check the ‘X-Died’ header as well.

use LWP::UserAgent;
my $ua = LWP::UserAgent->new;
my $response = LWP::UserAgent->get('http://example.com/foobar');

if ( $response->is_success && !$response->header('X-Died') ) {
   ...
}

That seems like a lot of work, so I’ve proposed a workaround that will at least warn on the fact that the ‘X-Died’ header exists. I don’t know what the right answer is, but I do know that the current behaviour is confusing.

Upgrading Business::PayPal::API

I got co-maint on Business::PayPal::API about 3 years ago in order to patch one line that was throwing a warning. The previous release had been 2 years prior to that. So it’s fair to say that this module has not lately been on a rapid release cycle. It’s still in use, though, and lately there has been some activity on rt.cpan.org related to it. So, I finally took an evening to sit down and try to cut a new release.

I got the bulk of the work done last night. I had been partially through a conversion to Dist::Zilla. I was able to finish that yesterday. This evening I finally got my head around how to get the tests running. It’s a non-trivial process.

There are a huge number of commits that I merged in for this latest release. All of the tests are passing except for one related to searching for “mass pay” payments. It’s in t/advanced/TransactionSearch.t. To be honest, that test failure doesn’t concern me too much. I don’t have a pile of time to invest in this at this point and my main concern is not breaking anything that involves sending and receiving payments. I’m also not sure when this test was actually last passing since most of the tests don’t actually run when the module is installed. That all predates me.

I’m pragmatic enough to say that I can either try to fix this test at some point over the next 3 years or cut a new release now and get this thing out the door. I really do want to get this out into the wild. If it turns out there is an actual issue with the mass pay search, I hope someone will pitch in with a fix.

If you rely on this module, please consider giving the TRIAL release a test run. Pull requests are happily accepted.

If I’ve heard no complaints by Oct 15, 2015 I will make a proper release including these latest changes.

Edit: I just checked the current latest release and TransactionSearch.t fails there as well, so this test failure is at least 3 years old, which means it’s not a blocker to putting out a new release.