Hi all,
Could someone clarify the purpose of pzAddWorkItemInHistory in Pega 26.1.1? After the upgrade, we noticed a sudden influx of queue items in this Queue Processor.
We also found an application setting used in the QP activity, pyAuditHistoryRetryForQP, which controls the maximum retry count and is set to 10 by default. Would it be appropriate to reduce this to 2 or 3? Is there a recommended value for this setting?
Any insight would be greatly appreciated.
Hi,
pzAddWorkItemInHistory is an internal Pega Queue Processor responsible for asynchronously persisting work item events to the case history. It helps maintain the audit trail by recording case-related activities in the background.
Regarding the increase in queue items after upgrading to Pega 26.1.1, it would be worth investigating whether the upgrade introduced any changes in processing behavior, database performance, or retry handling.
We also found that the application setting pyAuditHistoryRetryForQP, which controls the retry count within the Queue Processor activity, is set to 10 by default across all production levels. Although the Queue Processor itself has pyMaxAttempts = 1, the activity handles retries internally.
Reducing this setting to 2 or 3 may increase the risk of losing history entries when transient failures, database contention, or lock timeouts occur. Since this setting appears to be the primary retry mechanism, I would recommend retaining the default value of 10 unless there is evidence that retries are contributing to the performance issue.
I could not identify a documented Pega recommendation to reduce this setting to a specific lower value. Before making any changes, I would suggest monitoring the Queue Processor backlog, reviewing the activity’s retry behavior, and identifying the root cause of the increased queue volume after the upgrade. Any proposed change should first be validated in a lower environment through load testing.
Has anyone observed similar behavior after upgrading to Pega 26.1.1, or can anyone share guidance on the recommended configuration for pyAuditHistoryRetryForQP?
Thanks in advance for your insights.
Thanks for your response. So, is pzAddWorkItemInHistory the new approach for writing case audit history for workflow changes and other updates? We are seeing these events being triggered across the application during case workflow migration, as multiple users are working on it.
Hi Jeyachandra,
From our investigation, pzAddWorkItemInHistory is an internal Queue Processor that handles case history entries asynchronously. However, I haven’t been able to confirm whether this is a newly introduced approach in Pega 26.1.1 or an existing mechanism whose behavior has changed after the upgrade.
Your observation about these events occurring across the application during case workflow migration is interesting. The increased queue volume could be related to the number of case updates and history entries generated while multiple users are working concurrently, but we would need further evidence to establish the exact cause.
It would be helpful to confirm whether Pega 26.1.1 introduced any changes to case history processing or whether this increase in queue activity is expected during workflow migration.