SMS Action/Triggers fail on "blank" sms_carrier

[Chris Sharp]

Because of the nature of dojo-based dropdown menus, it is possible for a patron registered in the XUL client's patron registration editor to end up with a correctly-set Default SMS/Text Number and a Default SMS/Text Carrier of "" (the empty string). When the get_sms_gateway_email A/T reactor subroutine fires, it checks to see if the SMS number is defined/non-blank, but does not do a similar check of the SMS Carrier. In our case, this situation resulted in this error:

2017-05-30 20:10:26 utility01 open-ils.cstore: [ERR :12617:oils_sql.c:5800:] open-ils.cstore: Error with query [SELECT "csc".id AS "id", oils_i18n_xlate('config.sms_carrier', 'csc', 'name', 'id', "csc".id::TEXT, 'en-US') AS "name", oils_i18n_xlate('config.sms_carrier', 'csc', 'email_gateway', 'id', "csc".id::TEXT, 'en-US') AS "email_gateway" FROM config.sms_carrier AS "csc" WHERE "csc".id = '';]: <REDACTED> <REDACTED>: ERROR: invalid input syntax for integer: ""#012LINE 1: ...eway" FROM config.sms_carrier AS "csc" WHERE "csc".id = '';#012

Following this, we see lots of "IS NOT CONNECTED TO THE NETWORK!!!" errors and eventual cstore children exhaustion, which at one point cascaded into a full utility server failure.

Branch on the way that is intended to fix the failing reactor issue.

Evergreen 2.11.1(ish)
OpenSRF 2.4.1
Ubuntu 14.04 LTS
PostgreSQL 9.4

[Chris Sharp (chrissharp123)]

Branch here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1694696_check_sms_carrier

Marking "High" importance since this resulted in great pain for us.

[Galen Charlton (gmc)]

It's not clear to me how running an invalid query as part of the get_sms_gateway_email TT helper would, by itself, result in cstore starvation or cstore backends losing their XMPP connections — I think there must have been something else going on — but regardless, the patch correctly avoids a pointless query. Pushed to master, rel_2_12, and rel_2_11, along with some unit tests. Thanks, Chris!

Also noting new OpenSRF wishlist bug 1699307; having the ability to redirect error messages to a scalar would have more readily permitted writing a regression test as well.