INC-185322 · Issue 668321
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-186898 · Issue 670313
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-156647 · Issue 626292
Improved disconnected requestor cleanup for FieldService
Resolved in Pega Version 8.4.5
A large number of requestors from FieldService with the status as 'Disconnected' were accumulating and causing performance issues. This was traced to the requestors not getting passivated due to users not logging out and new requestors being created for the same users next time, and was caused by the value of the DSS Initialization/PersistRequestor being set as "OnTimeout". When the DSS prconfig/timeout/browser/default is not configured, the default browser requestor timeout is 60 minutes. In this scenario, requestors were not passivating as the requestor passivation timeout was set to the refresh token lifetime for mobile users, which was very large and overwrote the DSS value. This has been resolved by removing the code which set the passivation timeout to the OAuth2 refresh token lifetime.
INC-171838 · Issue 651438
Added mail/telephone link to allowed CSP child frame
Resolved in Pega Version 8.4.5
After upgrade from v8.3 to v8.5, clicking on the mail / telephone link in the out of the box case participants gadget generated the Content Security Policy error "This content is blocked. Contact the site owner to fix the issue." Examination of the browser dev-tools console indicated the object refused to frame because it violated the Content Security Policy directive: "frame-src *". This behavior was specific to the Google Chrome browser, and has been resolved by adding code so the mailto: and tel: will be added to the frame-src when Data is selected under Child Frame-Source option. Unchecking the Data checkbox for Child Frame-Source on the policy landing page will remove these from allowed actions under CSP.
SR-D28719 · Issue 505967
Null archive check added to set import process status
Resolved in Pega Version 8.2.4
After running a 'prpcServiceUtils.sh import' which failed due to a low-level null pointer error, the job "IMPORTREQUEST-2" then incorrectly showed the status as 'IN PROGRESS' instead of 'FAILED'. In this case, the null pointer exception occurred because two imports were unintentionally happening at the same time: the process copied up the same set of archives to the service export directory, but the first import processed an archive and deleted it so that the second process failed to find it. When it exited with the null pointer exception, the status was not set to 'failed'. To resolve this, a null archive check has been added which will set the status to 'failed' if the archive is unsupported, corrupt, or not there at all.
INC-196389 · Issue 690786
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-201335 · Issue 690733
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-152057 · Issue 621208
S3 attachment migration handles LInk-Attachment with multiple instances
Resolved in Pega Version 8.4.5
After S3 attachment migration, some attachments were intermittently not opening and displaying an error relating to being unable to load the file. Investigation showed that the attachments that failed to open did not have a pxStorageType tag in the XML of the work item. After the migration is done, the corresponding Data-WorkAttach-File and Link-Attachment instances are updated to point them to the repository. In this case, multiple LInk-Attachment instances were pointing to the same Data-WorkAttach-File instances, so only one Link-Attachment was updated and all of the other instances pointing to the same Data-WorkAttach-File instance were rendered unusable. While there was a workaround of manually updating the storage type in the database, this has been resolved by updating "pzgetattachmentcontent","pzupdatesourcereferences", and "pzuploadcontenttoexternalstorage" to check whether attachment is already migrated or not using the boolean parameter "isAttachmentAlreadyMigrated" to ensure all of the other Link-Attachment instances for a particular attachment are updated. If a migration was done and all Data-WorkAttach-File instances are pointing to a repository with some Link-Attachment instances not updated, those will be updated by running the migration again.