INC-130695 · Issue 587659
Enhancements for upgrading in multi-tenant environment
Resolved in Pega Version 8.1.9
Some muti-tenant installations use the same applications or rule instances with the same pzInsKeys for different tenants. This can cause upgrades to time out due to the system fetching all pzInsKeys (which will have duplicates) and working with them in a default batch size of 500 each over 4 threads. This led to the same keys potentially being allocated and processed in different threads, resulting in duplicate processing and timeouts. This has been resolved by updating the select query to fetch the tentantid and pzInskeys in the MT system to avoid duplicate work in multiple threads. In addition, running Generate Declarative indexes fetches the pzinskeys and generates indexes for each record, but before generating, the existing index for the record is deleted and then inserted. Because the delete query to generate the index was not tenant aware, all of the records for the key were deleted for the tenants for that key, but the new index was created only in one tenant. This has been resolved by enhancing the DELETE query to be tenant aware, which will avoid deleting the indexes for all the tenants given an index key.
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 621211
S3 attachment migration handles LInk-Attachment with multiple instances
Resolved in Pega Version 8.6
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.
INC-142118 · Issue 597313
Data Migration Import/Export made more resilient
Resolved in Pega Version 8.6
The entire data migration operation (export or import) was marked as "FAILED" even if the operation failed for just one type of data. While managing the failure, the operation deleted any completed data flow runs as part of the clean-up and only retained the failed data flow runs for use in further analysis. Because the queued runs could not be deleted, the data migration case became a broken process. At the root of the issue, the data export work item was failing due to one or more DSM service nodes being non-functional based on a validation failure in the case type that runs a check for the presence of functional DSM nodes before starting the data migration operation. This validation can return false negatives, especially on Cloud where the nodes are usually swapped seamlessly without the function realizing it. In such cases, the validation function returned false despite the DSM service nodes being up and running. This has been resolved by adding handling for the failed data migration case by stopping and deleting the open data flows and by disabling the validation which checks for functional nodes.
INC-155908 · Issue 625217
Logic updated for handling future events in strategy tests
Resolved in Pega Version 8.6
After upgrade, there was an unexpected exception "EventStrategy error in SerializeUtil: Integer too large to read, Size:48" while retrieving the final BBK aggregate results during strategy tests with several different pre-existing customerIDs, and no results were returned. When aggregations are read, there is a check to make sure the system does not return empty records. The logic for determining whether there is empty data in the record was mistakenly reading the event count from the wrong bytes which were part of a date for 2023. This was due to the second byte of the year date in hex being interpreted as the start of the event count. As a workaround, results are returned if no pxOutcomeTime dates in the database are more than a year in advance along with all aggregate datasets being recreated on production immediately after upgrade from v8.1 to v8.5. To resolve this issue going forward, the logic has been updated to handle the errors, and future records will trigger a warning in the log with information such as "Event time greater than current time in clipboard page. Event Time = Mon Mar 10 14:46:27 UTC 2025, Current Time = Tue Feb 09 14:18:49 UTC 2021. Ignoring event...".