Raley notifications of the following types:

  • Jira issue event
  • Jira ServiceDesk request event
  • Jira project event
  • Jira version event

are implemented by listening to events published by host application (Jira/JSM). Specifically, we're listening to the following Atlassian events:

com.atlassian.jira.event.issue.IssueEvent
com.atlassian.jira.event.project.AbstractVersionEvent
com.atlassian.jira.event.project.AbstractProjectEvent
com.atlassian.servicedesk.api.event.ServiceDeskCommentEvent


When one of the above mentioned events is published, Raley is trying to find a Notification configurations related to the event and evaluates them. The evaluation here means that we're checking if Issue/Request/Project/Version referenced by the Atlassian event is matching the conditions preconfigured in Raley Notifications such as: Project, Issue type, Status from, Status to and JQL rule.


Sometimes you'll notice that although your configuration looks correct, Raley fails to run a specific Notification configuration. By checking Jira's log file you can see something like this:


/secure/WorkflowUIDispatcher.jspa [n.v.j.s.notifications.utils.MessageSender] attempting Messenger=In Progress -> Pending ID=9fe4e978-3cc5-4d70-a47b-d249e57c0f26
/secure/WorkflowUIDispatcher.jspa [n.v.j.s.notifications.utils.MessageSender] Messenger=In Progress -> Pending ID=9fe4e978-3cc5-4d70-a47b-d249e57c0f26 is NOT eligible for execution


In the example above we see that Notification configuration "In Progress → Pending" was not eligible for execution.


One of the reasons this issue arises is that Raley configuration is validated too early and the Jira index is not yet up-to-date or Jira issue history (that we rely on with status transition evaluation) is not saved yet. 


To overcome this problem you can try to offset processing of Jira/JSM events by Raley. By default, there's no waiting and the events are processed as soon as possible. You specify processing delay with EVENT_PROCESSING_DELAY property like shown below:

EVENT_PROCESSING_DELAY=30


In this example, all Jira/JSM events will be processed 30 seconds after they have occurred. 


You might be wondering what value is good as a starting point? We recommend that initially, you try offsetting event processing by 60 seconds. This amount should be sufficient to ensure that the issue you're facing could be fixed by delayed processing. If this helps, you can eventually downgrade this value to 30 seconds.