Issue

In Pega Platform™ '26.1.1  when child Cases are created programmatically via a service API and resolve through Straight-Through Processing (STP), the parent Case is rejected with the following error: 

The cover open count is incorrect; it is -1 

This error does not occur in Pega Platform '25.1.3. The behavior is a regression introduced in Pega Platform '26.1.1.

Symptoms and impact

When a parent Case spawns child Cases via an activity call chain and those child Cases complete STP through to Resolved-Completed status, the platform throws a page-rejection error and halts further processing. 

The parent Case's internal open-child counter (pxCoveredCountOpen) reaches -1 instead of 0. 

The child Case STP resolution flow is fully blocked, and any upgrade validation that depends on this pattern cannot proceed. 

Steps to reproduce

1. Create a parent Case via a service API payload.
2. The parent Case reaches an assignment step.
3. Submit the assignment to trigger child Case creation. 
4. The application executes the child Case creation activity chain:
   • CreateSubject → CreateChildCase → addWork → AddCoveredWork → SaveNew → pzInitializeNewCase → pzStartStageProcesses 
5. Each child Case initializes and processes through the Create stage, then advances to the Resolve stage. 
6. The child Case executes the Resolve Case process and transitions to Resolved-Completed status via STP. 
7. Pega rejects the page with the error: The cover open count is incorrect; it is -1 

Root cause

This is a product regression.  A change was introduced in Pega Platform '26.1.1, which moved deferred database operations to execute in the Queue Processor (QP) context. As a result, in step 5 of the pzUpdateAndDeleteAssignments activity, the local variable WOStatus is populated from the most recent deferred-save instance. In '25.1.3 that instance is available at resolution time; in '26.1.1 it is not, so WOStatus is set to blank. The already-resolved guard condition evaluates to false, causing the child Case resolution to execute twice. Each execution decrements pxCoveredCountOpen on the parent: first from 1 to 0, then from 0 to -1. 

Solution

This issue will be resolved in upcoming patch releases.In the interim, two options are available.  

Local Change (Workaround) 

Option 1 — Dynamic System Setting (no restart required) 

Set the Dynamic System Setting immediateSaveWorkHistoryItem to true in the affected Pega Platform '26.1.x environment. This ensures that Case status information is captured at resolution time, preventing the double-resolution path. 

Steps: 

1. In App Studio or Dev Studio, navigate to the Dynamic System Settings page. 
2. Locate or create the setting immediateSaveWorkHistoryItem in the Pega-Engine ruleset. 
3. Set the value to true and Save. 
4. Retest the STP child Case resolution scenario. 

Option 2 — Platform Hotfix 

Install critical HFIX-D3646 on the affected Pega Platform '26.1.1 environment. A system restart is required after installation. This hotfix corrects the platform-level behavior in the pzUpdateAndDeleteAssignments activity. 

The handling of work history information has been updated so that the current status of the child Case is correctly identified, regardless of how the history information is being processed. 

This prevents an already-resolved child Case from being processed as resolved again and ensures that the parent Case's open child-Case count remains accurate. 

References

Creating a child Case Type in Case Designer