SR-D44041 · Issue 513919
Local UUID cache will be updated when merge event is detected
Resolved in Pega Version 8.4
Cluster-related issues were seen in multiple production clusters. For some nodes in the cluster the Cluster Management screen showed all expected nodes with valid Node IDs displayed, and on other nodes the Cluster Management screen showed the node ID of itself, SERVER@localhost:5701. On an impacted node displaying the wrong ID, the Node Information landing page did not work and displayed the error "Unable to execute job on ." Multiple advanced agents running on nodes in the affected clusters, both with correct and incorrect IDs, also failed with a similar error "Unable to execute job on <node's job id>". This was traced to a merge performed after a split brain. To resolve this, the code has been updated to handle merge events: when the node UUID is changed as part of a split brain recovery, the local UUID cache will be updated when the merge event is detected.
SR-D51554 · Issue 514063
Local UUID cache will be updated when merge event is detected
Resolved in Pega Version 8.4
Cluster-related issues were seen in multiple production clusters. For some nodes in the cluster the Cluster Management screen showed all expected nodes with valid Node IDs displayed, and on other nodes the Cluster Management screen showed the node ID of itself, SERVER@localhost:5701. On an impacted node displaying the wrong ID, the Node Information landing page did not work and displayed the error "Unable to execute job on ." Multiple advanced agents running on nodes in the affected clusters, both with correct and incorrect IDs, also failed with a similar error "Unable to execute job on <node's job id>". This was traced to a merge performed after a split brain. To resolve this, the code has been updated to handle merge events: when the node UUID is changed as part of a split brain recovery, the local UUID cache will be updated when the merge event is detected.
SR-D52336 · Issue 518388
Local UUID cache will be updated when merge event is detected
Resolved in Pega Version 8.4
Cluster-related issues were seen in multiple production clusters. For some nodes in the cluster the Cluster Management screen showed all expected nodes with valid Node IDs displayed, and on other nodes the Cluster Management screen showed the node ID of itself, SERVER@localhost:5701. On an impacted node displaying the wrong ID, the Node Information landing page did not work and displayed the error "Unable to execute job on ." Multiple advanced agents running on nodes in the affected clusters, both with correct and incorrect IDs, also failed with a similar error "Unable to execute job on <node's job id>". This was traced to a merge performed after a split brain. To resolve this, the code has been updated to handle merge events: when the node UUID is changed as part of a split brain recovery, the local UUID cache will be updated when the merge event is detected.
SR-D64090 · Issue 525866
Local UUID cache will be updated when merge event is detected
Resolved in Pega Version 8.4
Cluster-related issues were seen in multiple production clusters. For some nodes in the cluster the Cluster Management screen showed all expected nodes with valid Node IDs displayed, and on other nodes the Cluster Management screen showed the node ID of itself, SERVER@localhost:5701. On an impacted node displaying the wrong ID, the Node Information landing page did not work and displayed the error "Unable to execute job on ." Multiple advanced agents running on nodes in the affected clusters, both with correct and incorrect IDs, also failed with a similar error "Unable to execute job on <node's job id>". This was traced to a merge performed after a split brain. To resolve this, the code has been updated to handle merge events: when the node UUID is changed as part of a split brain recovery, the local UUID cache will be updated when the merge event is detected.
SR-D53260 · Issue 524752
Added check for section refresh when files are attached offline
Resolved in Pega Version 8.4
After attaching files in offline mode, the files intermittently did not show up in the "recent attachments" list when performing any action on the attachments section. This was traced to the asynchronous reload of sections, and has been resolved by adding a condition in the sectionRefreshCallback() to check if the response matches with the correct reload element.
SR-D40053 · Issue 517528
GetNextWork will use pyID to create unique thread name
Resolved in Pega Version 8.4
After creating three cases, for example D-1, D-2 and D-3 in application 'App1', and then moving to application 'App2' using Switch Application, the GetNextWork function was displaying unexpected behavior. Clicking on 'get next work' three times picked up the three cases (D-1, D-2, D-3) as expected, but when a case was closed manually the last case's lock was removed from the table. For example, closing D-2 manually resulted in the lock instance for the last case ID (D-3) being removed instead of D-2. This was traced to the Get Next Work API creating the thread with the access group name, which meant that if multiple assignments were accessed through 'get next work' it was always cleaning the already opened assignment threads and only the last assignment thread was available. To resolve this, Instead of creating the thread name with accessgroupname, the system will use the work object's pyID to create the thread using a unique key.
SR-D38450 · Issue 505657
Added workaround to handle HiddenPropertiesToIgnore when a page is in Read Only mode
Resolved in Pega Version 8.4
A 'WrongModeException' was generated while trying to use the Data Transform pxHiddenPropertiesToIgnore to remove system properties from page. When the Datapage was set to Editable/Savable mode, the Activity ran without an error and executed the Data transform. When the Datapage was in Read only mode, the error occurred. This was traced to a process that previously was allowed to set a page to an empty string, but which was removed during recent work. To resolve this, four instances of pxHiddenPropertiesToIgnore that included Single Page Value properties have been updated by moving them to the bottom of the Data Page and changing them to an "Update Page" from a "Set".
SR-D35266 · Issue 509482
Check added to postOpenAssignment to support Ajax Container use
Resolved in Pega Version 8.4
After configuring an 'OpenAssignment' action on a begin button and giving the target as 'Dynamic Container', it worked as expected to open the assignment in a new tab on the Platform, but did not work from the Customer Service interaction portal. This was traced to the Customer Service portal using MicroDC to display the cases in the work area, which was not within the scope of the Ajax Container. Additional checks have now been added to the postOpenAssignment function to support this use.
INC-132169 · Issue 584760
NativeSQL will use inline rule resolution for core components
Resolved in Pega Version 8.6
After upgrade, nodes were going down with a heartbeat error. This was traced to issues with NativeSQL taking a very long time to generate queries due to the overhead in calling multiple complex functions to resolve rules. To correct this, updates have been made to resolve the standard set of functions used by core components inline in NativeSQL function resolution.
SR-D33934 · Issue 503335
Parent case lock properly released when child case is resolved
Resolved in Pega Version 8.4
After creating Parent-Child casetypes with default locking where the child case had the “Allow access to parent” check box checked, the temporary lock acquired on the parent during resolution of the child case was not released afterwards. If “Allow access to parent” was not checked, then the locks were released on both the parent and the child. This was traced to a combination of parameters used by the openIfStale() API where aUnlockOnCommit could be set to false despite the provided locking strategy expecting it to be true, as well as honoring UnlockOnCommit when maintainLockingStrategy is false. To resolve this, the system has been updated to always check whether the lock is available in the map already and if it is, then set unlockonCommit to true. Otherwise, under all cases, honor the passed-in unlockOnCommit value.