Bug 36307 - SMS::Send driver errors are not captured and stored
Summary: SMS::Send driver errors are not captured and stored
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Kyle M Hall
QA Contact: Marcel de Rooy
URL:
Keywords:
: 32381 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-03-13 17:16 UTC by Kyle M Hall
Modified: 2024-05-28 17:41 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
24.05.00,23.11.06


Attachments
Bug 36307 - SMS::Send driver errors are not captured and stored (7.32 KB, patch)
2024-03-13 17:38 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 36307 - SMS::Send driver errors are not captured and stored (7.36 KB, patch)
2024-03-15 00:34 UTC, David Nind
Details | Diff | Splinter Review
Bug 36307: SMS::Send driver errors are not captured and stored (7.46 KB, patch)
2024-04-05 09:52 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2024-03-13 17:16:29 UTC
If an SMS::Send driver succeeds, it returns a value that evaluates to true. Every driver I've inspected uses croak when it encounters a failure state.

When an SMS message fails to send, code hard codes the failure code to NO_NOTES (No notes from SMS driver).

We should store the real error in `failure_code` and display that if the failure code doesn't match a known failure code.
Comment 1 Kyle M Hall 2024-03-13 17:38:10 UTC
Created attachment 163116 [details] [review]
Bug 36307 - SMS::Send driver errors are not captured and stored

If an SMS::Send driver succeeds, it returns a value that evaluates to true. Every driver I've inspected uses croak when it encounters a failure state.

When an SMS message fails to send, code hard codes the failure code to NO_NOTES (No notes from SMS driver).

We should store the real error in `failure_code` and display that if the failure code doesn't match a known failure code.

Test Plan:
1) Apply this patch
2) Set SMSSendDriver to any value
3) Generate a pending sms message
4) Run the following query:
   update message_queue set status = 'failed', failure_code = "This is a test";
5) View the patron's messages, note the delivery note contains the
   contents of the failure code
6) Run the following query:
   update message_queue set status = 'failed', failure_code = "SMS_SEND_DRIVER_MISSING";
7) Reload the patron's messages, not the delivery note is now "The SMS
   driver could not be loaded".
Comment 2 Kyle M Hall 2024-03-14 19:12:23 UTC
*** Bug 32381 has been marked as a duplicate of this bug. ***
Comment 3 David Cook 2024-03-14 22:40:51 UTC
Just bumped into this yesterday so I understand better now.
Comment 4 David Nind 2024-03-15 00:34:11 UTC
Created attachment 163156 [details] [review]
Bug 36307 - SMS::Send driver errors are not captured and stored

If an SMS::Send driver succeeds, it returns a value that evaluates to true. Every driver I've inspected uses croak when it encounters a failure state.

When an SMS message fails to send, code hard codes the failure code to NO_NOTES (No notes from SMS driver).

We should store the real error in `failure_code` and display that if the failure code doesn't match a known failure code.

Test Plan:
1) Apply this patch
2) Set SMSSendDriver to any value
3) Generate a pending sms message
4) Run the following query:
   update message_queue set status = 'failed', failure_code = "This is a test";
5) View the patron's messages, note the delivery note contains the
   contents of the failure code
6) Run the following query:
   update message_queue set status = 'failed', failure_code = "SMS_SEND_DRIVER_MISSING";
7) Reload the patron's messages, not the delivery note is now "The SMS
   driver could not be loaded".

Signed-off-by: David Nind <david@davidnind.com>
Comment 5 Marcel de Rooy 2024-04-05 09:52:00 UTC
Created attachment 164463 [details] [review]
Bug 36307: SMS::Send driver errors are not captured and stored

If an SMS::Send driver succeeds, it returns a value that evaluates to true. Every driver I've inspected uses croak when it encounters a failure state.

When an SMS message fails to send, code hard codes the failure code to NO_NOTES (No notes from SMS driver).

We should store the real error in `failure_code` and display that if the failure code doesn't match a known failure code.

Test Plan:
1) Apply this patch
2) Set SMSSendDriver to any value
3) Generate a pending sms message
4) Run the following query:
   update message_queue set status = 'failed', failure_code = "This is a test";
5) View the patron's messages, note the delivery note contains the
   contents of the failure code
6) Run the following query:
   update message_queue set status = 'failed', failure_code = "SMS_SEND_DRIVER_MISSING";
7) Reload the patron's messages, not the delivery note is now "The SMS
   driver could not be loaded".

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 6 Marcel de Rooy 2024-04-05 09:52:13 UTC
FIXED        * Commit title does not start with 'Bug XXXXX: ' - eb3ef09d69

Following code could still be improved with error codes. (No blocker for me)
    foreach my $required_parameter ( qw( message destination ) ) {
        # Should I warn in some way?
        return unless defined $params->{ $required_parameter };
    }

    eval { require SMS::Send; };
    if ( $@ ) {
        # we apparently don't have SMS::Send. Return a failure.
        return;
    }

Similarly (no blocker for me):
return $sent;
If $sent is 0, this could use a specific error code, I would say. Now we fallback to NO_NOTES.
SMS::Send does not tell us much more, I am afraid.
Provide a follow-up if you like.
Comment 7 Katrin Fischer 2024-04-05 15:40:48 UTC
Pushed for 24.05!

Well done everyone, thank you!
Comment 8 Fridolin Somers 2024-05-23 12:03:24 UTC
Pushed to 23.11.x for 23.11.06
Comment 9 Lucas Gass 2024-05-28 17:41:01 UTC
Doesn't apply cleanly to 23.05.x, no backport.