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-133583 · Issue 584923

Rest connector supports extended chars in attachments

Resolved in Pega Version 8.3.5

When the pyRequestAttachmentPage clipboard page was populated with a file name that contained Latin supplemental 1 unicode characters (decimal values 160 to 255 - for example an umlaut), any extended characters were being converted to question marks (?) before the call was sent, causing the web service call initiated by Pega to fail. To better support this use, an enhancement has been added to support a multipart request with extended characters in the file name. This allows the pyRequestAttachmentPage to specify pyFileNameExtendedChars, allowing RFC 6532 mode to be toggled for multipart requests with attachments. This mode allows for UTF-8 encoding in the attachment file name header, rather than the default ASCII encoding.

INC-143461 · Issue 601841

Updated JSON DT nested page property handling

Resolved in Pega Version 8.3.5

In a JSON data transform, when using an "Update page" step on a single-page property, as a child step of an "Append and map to" step where a pagelist property is given, the pagelist was populated with only one result but the single-page property was treated like a pagelist and received multiple results. This has been resolved by updating the ClipboardJSONDeserializer implementation and downstream abstractions to support "clipboard only" relations as properties in nested PageLists.

INC-139297 · Issue 601421

JSON content type update

Resolved in Pega Version 8.3.5

An update has been made to ensure the content_type is set to application/json for JSON response.

SR-D16427 · Issue 497220

Multi-nodes rebuild LibraryMetadata to ensure all Rule-Utility-Functions are present on change

Resolved in Pega Version 8.3.1

When performing a complete Application import into a clean installation, references to certain Rule-Utility-Functions went unresolved during the initial assembly. Investigation showed that after introducing a new Rule-Utility-Library or Rule-Utility-Function on one node in a cluster and then generating that, the other nodes in the cluster did not have the correct LibraryMetaDataCache for that Rule-Utility-Library. Therefore assemblies on those other nodes could be bad and throw a runtime UnresolvedAssemblyError. This has been resolved by modifying the way the Library subsystem processes the node changes events for Library Generation to ensure that each node completely rebuilds the LibraryMetadata for that Rule-Utility-Library so it contains all the Rule-Utility-Functions.

SR-D32441 · Issue 502572

Multi-nodes rebuild LibraryMetadata to ensure all Rule-Utility-Functions are present on change

Resolved in Pega Version 8.3.1

When performing a complete Application import into a clean installation, references to certain Rule-Utility-Functions went unresolved during the initial assembly. Investigation showed that after introducing a new Rule-Utility-Library or Rule-Utility-Function on one node in a cluster and then generating that, the other nodes in the cluster did not have the correct LibraryMetaDataCache for that Rule-Utility-Library. Therefore assemblies on those other nodes could be bad and throw a runtime UnresolvedAssemblyError. This has been resolved by modifying the way the Library subsystem processes the node changes events for Library Generation to ensure that each node completely rebuilds the LibraryMetadata for that Rule-Utility-Library so it contains all the Rule-Utility-Functions.

SR-D22113 · Issue 498312

Multi-nodes rebuild LibraryMetadata to ensure all Rule-Utility-Functions are present on change

Resolved in Pega Version 8.3.1

When performing a complete Application import into a clean installation, references to certain Rule-Utility-Functions went unresolved during the initial assembly. Investigation showed that after introducing a new Rule-Utility-Library or Rule-Utility-Function on one node in a cluster and then generating that, the other nodes in the cluster did not have the correct LibraryMetaDataCache for that Rule-Utility-Library. Therefore assemblies on those other nodes could be bad and throw a runtime UnresolvedAssemblyError. This has been resolved by modifying the way the Library subsystem processes the node changes events for Library Generation to ensure that each node completely rebuilds the LibraryMetadata for that Rule-Utility-Library so it contains all the Rule-Utility-Functions.

INC-119646 · Issue 563696

RemovePrivateBlockedAndWithdrawnRAQs updated to avoid exception

Resolved in Pega Version 8.4.2

If the method removePrivateBlockedAndWithdrawnRAQs() (present on the AgentRuleUtils.java class) had both the "ignore personal rulesets containing checked out files" and "ignore "Blocked or Withdrawn agent" conditions set, raqsItr.remove(); ran twice and resulted in a java.lang.IllegalStateException. This could lead to undesired outcomes such as agents not showing up properly. To correct this, the code has been refactored to avoid running raqsItr.remove(); more than the necessary number of times.

INC-125193 · Issue 561461

Processed in last hour generated correctly

Resolved in Pega Version 8.4.2

After upgrade, the 'Processed in last hour' for pyFTSIncrementalIndexer (or any other queue processor) did not show the totals processed. This was traced to an error in a declare expression rule, and has been corrected.

INC-128654 · Issue 567410

Queue processor handling updated

Resolved in Pega Version 8.4.2

After upgrade, the queue processors were not processing all the items in the queue, however the value under the 'number of items processed in the last hour' in the Admin studio showed the value was equal to the total number of items in the queue. This was traced to the an incorrect offset kept by the queue processor in the data table (Data-QueueProcessor-Run-Partition). Because the incoming messages from Kafka have a lower offset than the one kept by the queue processor, messages were treated as duplicates and not processed. This has been resolved by adding a partitions-validation mechanism on QP startup. To assist in proper handling, any messages identified as potentially already processed will be moved to the broken messages queue.

SR-D85839 · Issue 550939

Support added for custom Kafka connection properties

Resolved in Pega Version 8.4.2

An enhancement has been added to allow specifying custom Kafka connection properties in the Data-Admin-Kafka data instance to allow connections to external Kafka through the common client configs, ssl configs, and sasl configs.

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