INC-194305 · Issue 681681
File Dataset wildcards updated for ADM storage
Resolved in Pega Version 8.7
Attempting to access the filepath was failing and an error was seen indicating "Could not obtain lock 'Create repository file pegacloudfilestorage:ADM/Rule-Decision-AdaptiveModel/Data-Decision-Request-Customer". While creating a file name, a lock is generated while checking the file names of existing files. If the file data set has a large number of files, a condition may occur where some threads are unable to save data and an exception is thrown. To resolve this, the wildcard previously used in the file name has been replaced with the Pega node id + thread id + current timestamp. This will ensure all wildcards are unique and there is no need to lock and list existing files.
INC-170721 · Issue 658960
Stricter criteria set for reusing an SSAExecutionContext
Resolved in Pega Version 8.7
After a Strategy was configured with an existing Proposition Filter and the Explain Results box was unchecked, executing the strategy resulted in the error "Stack is empty, cannot pop any more frames". Investigation showed that the SSAExecutionContext object was reused across the two criteria evaluation in Proposition Filter rule: this works well as long as the input is the same across the two evaluations. However, the SSAExecutionContext object also stashed a reference to a PublicAPI object which became stale in the second evaluation and caused the empty stack issue for the given scenario. This has been resolved by providing stricter criteria in deciding when an SSAExecutionContext can be reused or not in the case of Proposition Filter rule.
INC-182776 · Issue 666941
CheckFlowDependencies updated for auto-instantiated child cases
Resolved in Pega Version 8.7
A parent case with more than one child case was producing an unexpected behavior during the child case creation process. The first child case was instantiated at the correct point of the case stage based on its dependency condition, but the following cases were instantiated at the same point where the first child case was created irrespective of the dependency conditions defined in the other child cases. Investigation showed that the pxCheckFlowDependencies activity called from the Resolve activity was removing the named pages "pyTopCaseMap" "pyTopCaseWork" which are required for starting and validating configured auto-instantiate child cases in the pzCanStart function. To resolve this, an update has been made to CheckFlowDependencies which will use the activity "pzResolveCaseHierarchyMap" for removing the "pyTopCaseMap" and "pyTopCaseWork" pages based on DependencyType.