Lib(Pega-RULES:BusinessCalendar).addTime uses stale D-A-Calendar
The system behaves different for different nodes after Calendar (Data-Admin-Calendar instance) update. All the nodes did not use the same version of Calendar. The Calendar was delegated to different users. The Calendar could be updated at any time, and on any node.
However, the update was not propagated to the other nodes. The SLA calculated for cases were different for each node.
Steps to Reproduce
Use a multi-node cluster.
Open a calendar instance on node A, update business hours.
Save calendar instance.
Execute a rule that uses the addTime function on node B.
Observe that stale DATA-ADMIN-CALENDAR instance is used by this function.
This issue was determined to be a product enhancement request.
The issue is working as designed.
A Calendar is an instance of Data-Admin-Calendar, originally (back to design time few years ago), high availability was not on the horizon and restart was considered routine. We also believed that updates to a Calendar would be rare events. So it has been decided to cache the Calendar instances. In other words, if the system has to use the Calendar, it will cache it, and obviously each node is having its own cache.
When a user is deciding to update a Calendar, his change will only be applied on the node he is working on and the associated cache will be refreshed. Unfortunately, if the Calendar has been cached on the other nodes, the system on those nodes will be using the previous version of the calendar.
This is why the help file is stating that a restart is needed. By design, we cannot guarantee that all nodes will be having the new version of the Calendar. As you already know, if you do not want to restart, you can also resave the Calendar on all nodes.
The change required is to enable the com.pega.pegarules.priv.businessCalendar.CalendarUtility to be modified on the fly, without the requirement for a node restart. This requires a complete design change to make the component cluster aware. The work to make the change would be pretty significant and is not something that can be done via hotfix.
As it stands, no fix is available. Not even in 7.1.9 which an existing Support Article (SA-7780) refers to as having the change included. In fact the behaviour of this piece of functionality has been the same across all available PRPC 6.x and PEGA 7 versions of the software.
An enhancement request, FDBK-15620 has been created for consideration by Pega Product Management.
The customer will mitigate this problem via their support documentation and procedures for the time being.