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-161829 · Issue 645199

EditElement Indexoutofbound exception addressed

Resolved in Pega Version 8.5.4

Attempting to run the activity pyEditElement was failing with an IndexoutofboundException error. Because Java compiles circumstanced pyEditElement sections in the system from the non-circumstanced base version that exists only in the @baseclass, the java compilation of the pyEditElement can end up exceeding the 65 000 byte threshold as the number of Decision Data rule instances and the corresponding properties grows across multiple ruleset versions. As an intermediate fix for the Indexoutofbound exception, the ruleset version has been removed from the circumstance value to reduce the java generation. Please note that this may result in a decision data rule that was created or updated in a branch and then merged to a ruleset version failing a subsequent checkout from the same merged ruleset version. Further work will be done on this issue in the next update.

INC-163597 · Issue 634741

Node stability improved when adding relevant records

Resolved in Pega Version 8.5.4

A node was going down after maxing out the database connection pool whenever the inbound service call was invoked. This was traced to several relevant record-related database queries being invoked within a short time for marking 'when' rules referenced in the proposition filter rule as relevant records. This has been resolved by adding 'when' rules as Relevant Records based on a DSS and not adding auto-generated 'when' rules at all.

INC-163723 · Issue 633440

Queue Processors made more robust

Resolved in Pega Version 8.5.4

After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.

INC-164581 · Issue 634155

Import UI option updated to handle data import for upgrades

Resolved in Pega Version 8.5.4

After upgrade from Pega 8.1 to 8.5, importing data into the datasets using the Actions->Import UI option was not working. This was due to the previous save operation used in import being deprecated, and has been resolved by instituting a new save operation in import to handle this scenario.

INC-165513 · Issue 645683

Queue Processors made more robust

Resolved in Pega Version 8.5.4

After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.

INC-165704 · Issue 639504

VBD data flow timeout increased and made configurable

Resolved in Pega Version 8.5.4

Intermittent VBD timeouts were seen when writing records to MSK even though no errors were reported on the MSK side. Analysis showed that while batch data flows retry when a timeout occurs, real time data flows do not retry and the configuration to wait up to 10 seconds for an acknowledgement may not be sufficient depending on the system conditions. This has been resolved by increasing the default timeout to 20 seconds and adding a configurable timeout "vbd/streamPublishTimeoutMillis" to allow a customized setting.

INC-166230 · Issue 638268

Updated timing for canvas flow refresh

Resolved in Pega Version 8.5.4

After launching the PegaCRM Suite and logging in, launching the Customer Decision Hub portal and clicking on Content->Actions from the left navigation menu to open the BlueLabel action rule generated an "invalid operation" error message. This was traced to the flow refresh happening before the canvas was fully loaded, which was caused by an independent canvas refresh being called from a different js rule after rule check out. This was a missed use case that resulted in a race condition, and has been resolved by ensuring the framework handling the canvas flow refresh waits for the canvas "Viewer" object to be created first before triggering a refresh.

INC-166354 · Issue 637301

Queue Processors made more robust

Resolved in Pega Version 8.5.4

After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.

INC-166561 · Issue 645649

ADM Models correctly updated

Resolved in Pega Version 8.5.4

The ADM models were not being updated when responses were processed either via the CaptureResponse API or when the time elapsed that should result in an update reflecting a non-response. This was traced to incomplete handling for a response coming for some other model which was converted to _EMPTY_, and has been resolved by modifying the logic so that the default responses and other responses are processed properly.

INC-167334 · Issue 639317

GRS support added for Kafka Key password

Resolved in Pega Version 8.5.4

An enhancement has been added to support using GRS to set values for the Kafka Key password dynamically.

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