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-D37317 · Issue 512553

Run Ruleset Cleanup defaults to true

Resolved in Pega Version 8.2.6

After upgrade, the rule categories and rules were not showing correctly in the App view of the Dev Portal. Many warning messages were also logged related to the Decisioning DM Sample application. This was traced to the rules cleanup script not running properly. While there was a workaround of applying the ruleset cleanup scripts manually after removing the queries that reference the pr_engineclasses table, the cleanup will now be set to run by default (run.ruleset.cleanup=true). In addition, the logic to determine which RuleSets to include has been simplified and most of the pr4_rule_vw deletions have been combined.

SR-D38318 · Issue 519710

Data pages explicitly cleared after QP use

Resolved in Pega Version 8.2.6

The Util Node was showing as Offline in the Search Landing Page, and when Jobs were submitted for execution from other Nodes the message "Detected active run with unreachable nodes" was logged. The util node, configured as a backgroundprocessing node, was running QPs; the queue size for custom QPs is 500 messages /queue items per minute, but investigation showed the requestor level and thread level data pages corresponding to the QP activities were not being cleared after use. This led to high heap memory issues that made the node unreachable, and has been resolved by adding code to explicitly remove the data pages when processing has finished.

SR-D48396 · Issue 520423

Hazelcast upgraded to resolve node startup issue

Resolved in Pega Version 8.2.6

Post data upgrade, the ADM tier failed to start and the error "java.lang.IllegalStateException: Node failed to start!" appeared. This was traced to a dormant bug in Hazelcast 3.11 that caused starting nodes to fail when the Hazelcast master node was shutting down, which was exposed by recent Pega changes made to enable parallel restarts of nodes in Cloud environments. Hazelcast delivered a fix for the parallel restart problem and the hotfixed jar has been merged into the platform. In addition, previous logic for loading Admin Studio waited 30 seconds before timing out when fetching information for each node. This caused issues with large clusters and Admin Studio not loading. The logic has been updated in the Admin Studio UI to load the page despite delays/issues waiting for nodes to respond to the gathering of cluster data, and the algorithm to detect remote-call timeout has been updated and is applicable to batch operation.

SR-D48433 · Issue 514857

Exception handling added for Redirect URL fetched from GRS

Resolved in Pega Version 8.2.6

When the application definition under “integration and security" tab was configured to use "Store in web storage provider" to allow choosing the storage name and the authentication profile, configuring the authentication profile to use an OpenID connect provider with the pyEndpointURL property given as a global resource setting such as (=D_SharepointDetails.url) was not working as expected. Clicking browse in the application definition sent the request to the OpenID connect provider and was returned with the error "The reference =D_SharepointDetails.url is not valid. Reason: Page name (D_SharepointDetails) from indirect reference was not found." This was traced to the Redirect URL (fetched from GRS) throwing an unhandled exception, and has been resolved.

SR-D48762 · Issue 518298

Enhancement added to support DB2 CREATE OR REPLACE view syntax

Resolved in Pega Version 8.2.6

After creating the product, attempting to import it on another environment failed due to incompatibilities with the syntax. In SQLGeneratorDb2.getViewSourceStatement(), when the View definition is fetched there is a check whether the view starts with "CREATE VIEW". Since the customer view of "CREATE OR REPLACE" was not supported in Db2LUW, it didn't match and appended the "CREATE VIEW" statement again. This happened only when using DB2, and has been resolved by updating the logic in SQLGeneratorDb2.getViewSourceStatement() to support CREATE OR REPLACE VIEW statements.

SR-D49804 · Issue 518226

Hierarchical view support added for moving packages

Resolved in Pega Version 8.2.6

After exporting a package from a DEV environment, attempting to import it to a TEST environment resulted in the query becoming corrupted and the process failing. This was traced to the regex used to fetch the select statement table name not supporting hierarchical views, and has been resolved by adding that support.

SR-D51324 · Issue 523434

Authentication state refreshed after failure in mobile

Resolved in Pega Version 8.2.6

When using the mobile app, if the log in was started and incorrect credentials or empty fields were submitted and then the credentials screen was X-ed out or canceled, attempting to log in again using the correct information still received the "Authentication failed" error. A subsequent attempt with the correct credentials would then work. This was traced to the server persisting the state from the first request (per browser session), and has been resolved.

SR-D53835 · Issue 524213

Handling added for custom authentication in embedded mashup

Resolved in Pega Version 8.2.6

After embedding the Mashup gadget in an external application, at browser refresh a Cross-Origin Read Blocking (CORB) warning appeared and the gadget did not load as expected. A second refresh cleared the error. Investigation showed that when custom authentication is configured, 'use SSL' is checked in Authentication service. That meant that when the user was authenticated, the redirection was not considering the query string entered before authentication and the CORB warning was issued due to a change in response. Because there is special handling for the above use case and post-authentication redirection does not happen through the normal flow (HttpAPI), this issue has been resolved by honoring the query string stored in requestor (entered by user) while redirecting.

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