That just means that the hold was either picked up or cancelled between the time that the event was generated and when the A/T system reacted to it, or that the reaction to the event was blocked due to circumstances such as the lack of an email address for a patron in an email reactor. That prevents spurious notifications from being sent, or errors from occurring. The behavior is intended.
HTH, Regards, Mike Rylander -- Sent from my phone, please pardon my thumbs. | President | Equinox Software, Inc. / The Open Source Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com On Sep 15, 2015 8:02 PM, "Jeff Green" <[email protected]> wrote: > We're seeing some percentage of our hold notification events going to > "invalid" state. Any ideas what type of problem would cause this? > > I've been looking for any commonalities such as requester, user, hold > type, time the event triggers, and so far can't find any such common > attribute associated with the "invalid" vs. "complete" states. > > I also reviewed the logs for errors in a 2-hour window around a recent > "invalid" event and they are clean. Any suggestions for further > troubleshooting are welcome. > > Here's an example of what I am seeing in the database: > > state | name | count > ------------+------------------------------------------+------- > complete | Hold Ready for Pickup Email Notification | 63 > invalid | Hold Ready for Pickup Email Notification | 26 > > > Thanks, > > -- > Jeff Green > >
