action_trigger - support immediate event processing

Bug #1745216 reported by Josh Stompro on 2018-01-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

Hello, while discussing a possible new feature of having a way for staff to fire off test messages to customers to test their notification settings, it was brought up that it would be nice if the test message happened as close to instantly as possible.

http://masslnc.org/node/3154#comment-2154

I think that the feature would use the action_trigger system to send the test messages. Which uses cron to run action_trigger_runner.pl at regular intervals. The minimum cron run time is every minute. Which would add a delay between 0 and 60 seconds before the events are processed and test notifications sent.

If a customer is standing in front of you, or is on the phone with you, it would be nice for the test messages to happen quickly consistently to save staff time and customer time.

Another use case would be for the customer welcome emails to get sent off as soon as a new patron record is created, so any bounce backs get to staff asap, so staff can talk to the customer immediately about why their email didn't work.

And yet one more use case is for the password reset emails. It would be good customer service to get those sent asap so that the reset message is in the customers inbox as soon as they go from the catalog login form to their email.

One method of making this happen may be to use the postgres listen/notify feature which allows one process to listen for an event notification fired off by another process. There could be a trigger setup on action_trigger.event that runs notify command whenever a new row is added, or when the add_time changes for a row. It could just always send the granularity value as the channel. Then there could be another process on the utility server that uses listen to look for new events for whatever granularity is wanted, and then fire off action_trigger_runner.pl for that event. Once action_trigger_runner.pl returns, check for missed events that came in while executing, then go back to waiting for a new event.

Postgres LISTEN docs - https://www.postgresql.org/docs/9.4/static/sql-listen.html
Postgres NOTIFY docs - https://www.postgresql.org/docs/9.4/static/sql-notify.html
Perl script example for waiting for events - https://<email address hidden>
More examples and discussion - https://omniti.com/seeds/stop-collaborate-and-listen-notify

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers