Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

INC-167311 · Issue 646477

Updated upgrade handling for migrating work objects

Resolved in Pega Version 8.3.6

After upgrading from Pega 6.2 to 8.3, the work migrated work objects were missing SLAs due to missed entries in the assignment tables (PC_ASSIGN_WORKLIST/ PC_ASSIGN_WORKBASKET) . The SLA was firing, but the processing failed due to the fact the runtime could not resolve a 'AddHistoryPage' library function. In this case, multiple upgrades of the application dating back to Pega 4 resulted in the runtime context containing older ruleset versions in higher ruleset versions, hiding the underlying Pega 8 version of the rule. For releases prior to Pega 7.3, Rule-Application was stored in pr4_rule and will be migrated to pr4_rule_application during upgrades. However, since Context Upgrade is run before Optimize Newly Exposed Columns, the pyDependsOnName won't always be populated. To resolve this, the system will filter based on the value in the blob rather than the exposed column so there will be a value regardless of the upgrade-from version.

INC-172675 · Issue 649451

Configuration added for extending queue processor timeout

Resolved in Pega Version 8.3.6

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.

SR-C98068 · Issue 483991

Installer files updated with class loader conflict resolution assistance

Resolved in Pega Version 8.2.4

When sending emails with attachments, errors were observed relating to a loader constraint violation indicating that when resolving interface method, the class loader of the current class and the class loader for the method's defining class had different Class objects for the type used in the signature. The resolution for this requires user configuration of the app server, and the following files for the install guide have been updated with the appropriate information:Deployment-guides-dita/install.ditamap Deployment-guides-dita/Content/Topics/app-server-config/creating-jdbc-driver-module-jboss-tsk.dita Deployment-guides-dita/Content/Topics/app-server-config/delegating-javax-activation-to-JRE-loader-tsk.dita

SR-D28460 · Issue 509365

Added timeout handling for non-PRAuth servlets

Resolved in Pega Version 8.2.4

After logging in via external authentication service (SAML Single Sign On) and setting up a timeout in the access group RuleForm, when the user performed any action and the server identified the request to be timed-out, it was expected that a SAML request would be sent from the browser to the external Authentication Server (referred as IDP) and the flow would proceed from there. This worked as expected for a non-AJAX request. To resolve this, handling has been added for timeout when using non-PRAuth authentication services.

SR-D29127 · Issue 506863

SAML data pages restored after passivation

Resolved in Pega Version 8.2.4

If login used SAML SSO, resuming the session after passivation resulted in missing or empty data pages when using an SAP integration with Pega Cloud. This was traced to a security change that modified the D_SAMLAssertionDataPage and D_SamlSsoLoginInfo data pages as readonly, causing them to not be passivated under these conditions. To resolve this, the data pages have been made editable so they will be restored as expected. This change also resolves any difficulty with SAML logoff activities in conjunction with SAP and Pega Cloud.

SR-D37872 · Issue 507341

prproductmigration build.gradle updated for new mime4j asset name

Resolved in Pega Version 8.2.4

While running the getMigrationLog for ProductMigration script provided in the Pega 8.2.2 media files, errors appeared referencing "NoClassDefFoundErrors when running getLogs". This was caused by the referenced class not being found on the classpath: the version of the included jar did not include the class needed due to Praxiom's default version being updated to use a new version of mime4j that required an asset name change. To resolve this, the mime4j asset name in prproductmigration build.gradle has been updated to pick up the correct version of the dependency for Praxiom.

INC-145293 · Issue 610935

Additional diagnostic logging added for ElasticSearch startup issues

Resolved in Pega Version 8.5.6

The PyIndexerState was stuck in Starting status during node initialization. This issue could occur if the filesystem became hung due to network level issue while scanning entries from /etc/mtab, resulting in a lock which was not released correctly. In order to better determine which node entry in a cluster may be responsible for the hang, an update has been made which will use a temporary virtual environment to repeat the part of the initialization phase responsible and generate additional logs for debugging. To activate this, the PegaSearch.Diagnostics logger must be set in DEBUG mode. This duplicated virtual initialization will not interrupt the normal initialization.

INC-163791 · Issue 666195

Simplified default reference time calculations

Resolved in Pega Version 8.5.6

After a job scheduler was configured to run at Start time = 21:00:00 for Time zone = Europe/London, the scheduler determined 20:00:00 as the next start time. This was due to the calculation for the next start time using the time zone offset calculation pattern for the date and time stored in System-Runtime-Context.pxCreateDateTime, which had difficulty with changes to the time zone definition implemented in the time between the given date and today (meaning the current time) such as daylight savings time. To resolve this, the default reference time from System Runtime Context will be 'now' instead of Date(0).

INC-168253 · Issue 660882

Documentation updated for using Connect MQ with clustered queues

Resolved in Pega Version 8.5.6

After update to Pega Platform v8.6, an issue was seen with Connect MQ rules that used an alias queue. The support documentation has been revised to outline the necessary steps for updating an application to perform as expected. In the Pega-IntegrationEngine ruleset, create the following dynamic system settings and their default values: "mq/pmo" = 0 "mq/gmo" = 0 "mq/oo_request" = 1040 "mq/oo_response" = 16 For more information, dynamic system setting support articles are available.

INC-174625 · Issue 655241

Admin Studio will consider cluster protocol when returning listener status

Resolved in Pega Version 8.5.6

When using a few nodes in standalone mode for BIX extract combined with server nodes using Hazelcast, opening the admin studio pages with service discovery caused an error to be thrown. This was traced to the system writing an entry to pr_sys_statusnodes table as an embedded node whenever a BIX extract was triggered, causing those standalone nodes to be incorrectly considered by the listener landing page. This has been resolved by configuring the system to either return the local member when the cluster protocol is standalone or to return all Hazelcast members if the cluster protocol is Hazelcast.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us