GOS Revisions Become STALE After Unrelated Deployments with STATIC_CACHE – Pega 24.1.1

General
, ,
1

Pega Platform Version: 24.1.1
DSS: cacheGOSProgram
Configuration: STATIC_CACHE

Hi Pega Community,

We are experiencing an issue with Globally Optimized Strategies (GOS) in Pega Platform 24.1.1 and would appreciate clarification regarding the expected behavior of STATIC_CACHE.

Background

We have several deployments throughout the day. To avoid frequent GOS recompilation and its potential performance impact, we changed the cacheGOSProgram DSS value from SMART_CACHE to STATIC_CACHE.

Our expectation was that previously compiled and optimized GOS programs would remain available and continue to be used unless their actual strategy dependencies changed.

Issue Observed

After deploying an application package that, to our knowledge, does not contain any changes related to the GOS strategy or its dependencies, we observed the following:

  1. All revisions of the affected GOS became STALE in the Strategy Optimizations screen.
  2. No CURRENT revision remained available.
  3. Inbound processing continued to work without any reported issues.
  4. During outbound processing, an error was reported indicating that the GOS could not be found or was unavailable.
  5. We also received feedback about degraded performance, although no significant traffic increase was observed.

We have not yet confirmed whether the outbound error and performance degradation are directly caused by the STALE revisions.

Expected Behavior

Our goal is to keep STATIC_CACHE enabled and continue using the latest successfully compiled GOS revision when deployments do not affect the GOS or its dependencies.

We would like to avoid unnecessary recompilation during frequent deployments while ensuring that outbound processing continues to use an optimized GOS program.

Questions

  1. Is it expected behavior for GOS revisions to become STALE after a deployment when cacheGOSProgram is set to STATIC_CACHE, even if the deployment does not modify the GOS or its dependencies?
  2. Does STATIC_CACHE only disable automatic recompilation, or is it also expected to preserve previously compiled GOS revisions?
  3. If all GOS revisions are STALE, can the runtime still execute the latest compiled GOS program? Or will it fail, fall back to non-optimized execution, or attempt recompilation?
  4. Is there a supported way to prevent unrelated deployments from invalidating existing GOS revisions while keeping STATIC_CACHE enabled?
  5. If manual recompilation is required, is saving the GOS rule after deployment the recommended approach to generate a new CURRENT revision? Is there another supported method for automating this as part of the deployment process?
  6. How can we verify which GOS revision is actually used during outbound execution?
  7. Are there any known issues or fixes in later Pega 24.1.x patch releases related to unnecessary GOS invalidation or revision management?

Additional Context

We are considering a controlled deployment process in which we complete the deployment, manually recompile the affected GOS rules if necessary, verify that a CURRENT revision exists, and then validate outbound execution.

However, our preferred solution would be to prevent unnecessary invalidation when the deployed package does not affect the GOS.

Any guidance on the expected behavior of STATIC_CACHE, GOS revision invalidation, and recommended production deployment practices would be greatly appreciated.

Thank you!