SR-C8023 · Issue 350229
Updated dataflow used after pause/continue
Resolved in Pega Version 7.4
When using an event dataflow that has a Kafka dataset as the source, running the flow, pausing it, and importing updated rules was resulting in the resumed flow still using the old rules. This was a known limitation in the data flow metrics management where when a run was resumed, the previous metrics were "merged" with new metrics. In cases where the structure of a data flow changed between pause/resume, merge failed silently and new metrics were not saved to the database. The metric management has now been updated to merge metrics correctly: in case of a data flow structure update (e.g. shapes added/removed), after the data flow is run, stage metrics will be cleared up as it is not possible to match them with the new structure, and all other metrics will be properly resumed from the "paused" position (e.g. number of processed records, throughput etc.).
INC-143121 · Issue 610732
Timeout for loading predictors made configurable
Resolved in Pega Version 8.3.6
When using an extremely large number of predictors, the Report definition pzADMPredictorsFilter was suffering timeouts due to the time for loading predictors from the database exceeding the time threshold allowed. This has been resolved by marking the rule as editable to allow custom setting of the threshold according to need.
INC-148899 · Issue 615702
Adaptive models update correctly
Resolved in Pega Version 8.3.6
Some models had the recorded responses column updated, but the models (number of Positive, Negative and Processed Responses) were not updated. Investigation showed that deleting the modelRuleConfiguration through the stateManager/client did not delete modelFactories related to the configuration. If a new configuration came in with a different algorithm, the update issue occurred. This has been resolved by reseting the configuration according to its factory in that specific case.
INC-155822 · Issue 618267
Locking added to avoid null pointer error for auto-populate property
Resolved in Pega Version 8.3.6
After configuring the auto populate property "OrgProduct" which referred to a data page, the system experiencing heavy load led to the property not getting properly initialized. This resulted in a WrongModeException and NullPointerException. To resolve this, the system has been updated to lock the requestor when Queue Processors execute their activity. This will prevent race conditions and concurrent modifications if other threads are accessing the same requestor.
INC-157629 · Issue 626633
Duplicate key exception resolved for adaptive model
Resolved in Pega Version 8.3.6
During the model snapshot update, a DuplicateKeyException was generated while trying to insert a record in to the predictor table. This did not affect the model's learning, but did appear ion the model monitoring report. This was traced to a local scenario of having the same outcome values defined on the model with different cases (Accept and accept). All predictors used in an Adaptive model are inserted into the model monitoring tables as a part of the monitoring job: because the monitoring tables are not case sensitive, this lead to a unique constraint exception since there were multiple IH predictors with the same name. To resolve this, validation has been added which will skip adding duplicates from new responses.
INC-160331 · Issue 628710
ML model continue tag error changed to debug logging
Resolved in Pega Version 8.3.6
Log entries were seen indicating "The continue tag is found without a start tag for window Line1 1234567890 in text". This appeared to be coming from the MLCommand java class. Investigation showed this occurred when the ML model believed a portion of the text (token) was a continuation of the entity because it has not found the starting part of the entity. This situation is not currently treated as a valid output, so an update has been made to change the logging level from error to debug for this case.
SR-69015 · Issue 619995
Unescaping characters implemented for expressions
Resolved in Pega Version 8.3.6, Resolved in Pega Version 8.4.4, Resolved in Pega Version 8.5.3, Resolved in Pega Version 8.6
An issue where expression builder statements were evaluated differently at runtime than at testing has been resolved. Pega Platform expressions with String literals(that is, sequences of characters enclosed in quotation marks) now unescape characters in strategy shapes such as Set Property or Filter.
SR-D90367 · Issue 556687
Cleanup enhanced for long pyEditElement names
Resolved in Pega Version 8.5
A pyEditElement error relating to decision data was seen multiple times in a stack trace. Research showed that while the utility worked as expected for decision data rules with names of less than 30 characters, the pyEditElement section was truncated the name for the decision data. This meant that decision data with the name SampleIssueandSampleGroupTwosalkdjkightntbmkblffvfvfv would be saved as SampleIssueandSampleGroupT for the pyEditElement section. Because of this, the utility failed the match and did not clean up the pyEditElement section. To resolve this, the cleanup utility has been updated to handle pyEditElement sections of decision data with longer names. Additional logging has also been added to improve debugging.
SR-D71621 · Issue 533296
Real time processing picks up correct datetime for Capture Response records
Resolved in Pega Version 8.5
A Realtime Data flow for the Capture Response flow was configured with a strategy shape set to load previous decisions within the past 7 days. Once this Realtime DF was started, attempting to Capture Response for decisions made after that startup timepoint did not work. This was traced to the InteractionID being written with global properties for the datetimes, and has been resolved by making those datetime properties local so the start and end time are not cached and the time range is calculated based on "now”.
SR-D85558 · Issue 548286
Handling added for prolonged Heartbeat Update Queries
Resolved in Pega Version 8.5
After restart, the pyFTSIncrementalIndexer queue size had hundreds of thousands of entries even though it was empty prior to the restart. Investigation traced this to a job scheduler that checked all the database connections everyday at 1 EST by using a list that contained some connections which did not exist. Checking those invalid connections caused other update queries to queue and wait, resulting in the update heartbeat query taking longer than its default beat. This caused a Split Brain issue wherein other nodes considered the long-executing node to be dead and triggered a rebalance while the node itself continued to execute partitions thinking that it was healthy. This caused duplicate processing of records. To resolve this, a fail safe has been added: while updating heartbeat in Service Registry, nodes will enter safe mode when the update query is taking longer than the default beat.