Inconsistent return values in create volumes stack

[Dan Wells]

The create_volume() sub in AssetCommon.pm previously returned a failure event or an undefined value in the case of success. It now returns either an acn FM object or any one of a number of events, but makes no distinction in the return value. As such, unexpectant methods further up the stack (i.e. find_or_create_volume() in Application/Cat.pm) are doing nothing to handle these events.

It appears these issues result from the changes in bug #1678152. It also appears that there was some intention to alter the change_volume() return signature to a list, ($vol, $evt), but that was not carried out for the failure cases. It seems possible at first glance that changing these returns to (undef, $evt) is all that would be needed, but I have not yet investigated any possible side effects of carrying that through, or whether a better solution exists.

I believe this bug affects both 2.12 and 3.0.

[Kathy Lussier (klussier)]

Dan,

Do you think it's possible that this problem could be the cause of bug 1721133? Michele reports that the problem started occurring after their 2.12 upgrade.

[Dan Wells (dbw2)]

Kathy, looking briefly, I don't think so. The log entries on that bug showing the precise 1 minute gaps do seem to indicate a timeout problem, perhaps the same as bug #1704396 (as noted).

I expect this bug here to primarily surface on error conditions, such as trying to create a call number on an org which cannot have call numbers. I have not tested that. I just came across this code while reading through for a separate issue, and felt this looked fishy enough to write up.