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 update your bookmarks. This site will be discontinued in Dec 2024.

Pega Platform Resolved Issues for 8.1 and newer are now available on the Support Center.

INC-168003 · Issue 655376

BIX Total Instance count matches manifest

Resolved in Pega Version 8.6.3

The BIX Manifest file was showing a count mismatch when the BIX Manifest and Extract files were shared with downstream teams, causing data to not be accepted by the downstream application. Investigation showed this occurred for an embedded page list property in the sequence that was missed and not considered. To resolve this, a DSS has been added: when BIX/generateAllEmptySubscriptForPageList is set to true, an empty subscript will be generated for the missed properties.

INC-178002 · Issue 663769

Restore point handling updated for absent pzpvstream column

Resolved in Pega Version 8.6.3

While executing the “get restore point” action for rollback, a PZPVSTREAMerror error occurred with the message "(util.HistoryCollectorDataModel) WARN|Rest|SystemManagement|v2|restorepoint - History collection for the table will be slow because it does not have all of the required columns". This was a missed use case for Robotics Automation not having a pzpvstream column for one of the tables; this has been corrected with a check to validate for pzpvstream column so the system will not seek history records if the pzpvstream column is not present.

INC-181941 · Issue 664807

Handling added for using virtual network interface for Stream Services startup

Resolved in Pega Version 8.6.3

After update, the restart of any node failed with the error "Unable to create DSM service DATA-DECISION-SERVICE-STREAMSERVER DEFAULT". This has been resolved by adding support for allowing stream service to start on the virtual network interface in cases where it was explicitly configured via the "cluster/hazelcast/interface".

INC-183485 · Issue 681361

Updated background refresh for off-screen worklist

Resolved in Pega Version 8.6.3

After update, performance impacts were seen on the field service mobile app. This was traced to Worklist refresh, and has been resolved by adding an update which will postpone the refresh when the worklist webview is in the background (not visible on the screen).

INC-185117 · Issue 680900

Check added to disable offset support for older versions of Oracle

Resolved in Pega Version 8.6.3

An ORA-00933 error was generated after upgrading from Pega 7.1 to Pega 8.5. This was traced to a conflict between Oracle 11g and the Pega 8.5 platform related to an OFFSET statement being added to a query for a version of Oracle that doesn't support it. The preferred solution is to upgrade Oracle to address this, but in order to support backwards compatibility a check has been added which will disable offset support in Oracle if productversion <=11.

INC-189781 · Issue 677817

Database Transaction Log update overflow resolved

Resolved in Pega Version 8.6.3

When automatic.resume=false was encountered uring an update, cleaning up the existing codeset from previous updates ended up filling up the database transaction logs and caused the update to fail. This has been resolved by updating the process of clearing the codeset so it doesn't overflow the transaction log.

INC-190070 · Issue 676644

Restored local blocking queue cache

Resolved in Pega Version 8.6.3

After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.

INC-190070 · Issue 676900

Restored local blocking queue cache

Resolved in Pega Version 8.6.3

After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.

INC-192979 · Issue 679042

Cache support added for Runtime Context

Resolved in Pega Version 8.6.3

System performance has been improved by adding cache support for System-Runtime-Context management.

INC-193153 · Issue 686295

Restored local blocking queue cache

Resolved in Pega Version 8.6.3

After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.

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