OpenSRF.pm AUTOLOAD complicates testing / serves little purpose

Bug #1179660 reported by Bill Erickson on 2013-05-13
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
OpenSRF
Medium
Unassigned

Bug Description

OpenSRF.pm contains an AUTOLOAD handler which warns when unimplemented subs are called. The original purpose was to log calls to nonexistent subs to the opensrf logs. While this may be helpful, the fact that the AUTOLOAD results in a value of "1" (the result of the final warn()), nonexistent subs do not cause execution to stop. Instead, the code continues using a value of "1" as the result of the bogus call. This can result in very confusing problems, particularly when testing new code.

Removing the AUTOLOAD will allow Perl to produce similarly useful error messages while also stopping code execution (unless captured by an eval/try). For example, removing the AUTOLOAD on a test system produces the following error when calling a nonexistent sub, invoked from srfsh:

Received Exception:
Name: osrfMethodException
Status: *** Call to [open-ils.actor.user.retrieve] failed for session [1368474564.335152.136847456411193], thread trace [1]:
Undefined subroutine &OpenILS::Application::Actor::foobar called at /usr/local/share/perl/5.10.1/OpenILS/Application/Actor.pm line 1154.

-----

WARNING: Removing AUTOLOAD means any code which relies (intentionally or otherwise) on the lax nature of nonexistent sub handling in OpenSRF will now die with a fatal error, whereas before it may have limped along. Evergreen users, I'm talking to you! Of particular interest will be ensuring the open-ils.storage CDBI entries are kept in sync with the IDL (as needed), as this is a common cause of calls to nonexistent subs in Evergreen.

Patch coming shortly.

Bill Erickson (berick) wrote :

Patch pushed to working/user/berick/lp1179660-kill-autoload

Changed in opensrf:
assignee: Bill Erickson (erickson-esilibrary) → nobody
milestone: none → 2.1.3
tags: added: pullrequest
Galen Charlton (gmc) on 2013-05-13
Changed in opensrf:
milestone: 2.1.3 → none
Galen Charlton (gmc) wrote :

I've linked this bug to Evergreen as well, since CDBI subclasses defined there have historically been prone to not being fully synchronized with the schema, and removing the autoload will convert those mistakes into (run-time, alas) fatal errors. I do think that they *should* be fatal errors, but we should fix the ones we know about first.

I've also removed the milestone targeting for the moment -- if we can get away with releasing it just for OpenSRF 2.2.x, that would be my preference. Regardless, related Evergreen fixes (if any) will probably have to be backported to all supported Evergreen release branches, since we don't say that older Evergreen version series *must* use older OpenSRF versions.

Ben Shum (bshum) on 2013-05-24
Changed in evergreen:
status: New → Triaged
importance: Undecided → Medium
Changed in opensrf:
status: New → Triaged
importance: Undecided → Medium
Bill Erickson (berick) wrote :

I've started testing this with Evergreen. So far, I've only poked around the TPAC and run the hold targeter. I've found one fatal error in Search/Z3950.pm. I've started a branch to collect Evergreen repairs and pushed a fix for the Z39 issue.

Evergreen -> working/collab/berick/lp1179660-eg-opensrf-autoload-repairs

Galen Charlton (gmc) on 2014-02-28
Changed in evergreen:
milestone: none → 2.6.0-rc1
milestone: 2.6.0-rc1 → none
Galen Charlton (gmc) wrote :

To get some movement on this, I've pushed the one EG commit in working/collab/berick/lp1179660-eg-opensrf-autoload-repairs to Evergreen master, and I will soon push the OpenSRF commit to OpenSRF master.

This means that there is a decent chance that Evergreen master running on OpenSRF master may see some breakage, though i will do as much testing as I can in Evergreen master first.

Galen Charlton (gmc) on 2014-02-28
Changed in opensrf:
milestone: none → 2.4.0-alpha
Galen Charlton (gmc) wrote :

I've committed the OpenSRF patch to master. Thanks, Bill!

Changed in opensrf:
status: Triaged → Fix Committed
Galen Charlton (gmc) wrote :

By virtue of when I pushed it, it's been in Evergreen rel_2_6 since the beginning. I've now pushed it to rel_2_5 so that 2.5.x can work with OpenSRF 2.4 once it's realized.

Changed in evergreen:
status: Triaged → Fix Committed
milestone: none → 2.5.6
Changed in evergreen:
milestone: 2.5.7 → 2.5.6
Changed in evergreen:
status: Fix Committed → Fix Released
Galen Charlton (gmc) on 2016-02-04
Changed in opensrf:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers