Question
Jabil
US
Last activity: 13 Dec 2022 16:11 EST
Declare Expression collisions
Who else has been troubled with errors and/or log messages saying...
java.lang.IllegalStateException: Implementation error: encountered two expressions with the same target property size
In some cases it prevents us from saving a rule, but in most cases it generates gigabytes of log messages as users simply render UI. In our most recent encounter, it seems responsible for a memory leak that eventually exhausted heap. We've submitted multiple tickets, but we always fail to escalate to the right engineer and are eventually told to "fix your code".
My question for Pega is whether it's possible to include the property names in the error output. Otherwise there is no way to debug this except searching the haystack straw by straw.
The error is typically thrown by...
java.util.Map expression_metadata = tools.getInfEngUtils().getExpressionMetadata(aTopLevelPage );
... in Harness-ConfigureExpressions while generating the client side declare expression Javascript text. We've found reliable ways to reproduce it, e.g. specialize expression ".pxListSubscript" in another class. (Someone here tried that recently because the @baseclass version wasn't firing reliably in the subclass). But almost any case of specializing an existing expression is a candidate to cause it.
Who else has been troubled with errors and/or log messages saying...
java.lang.IllegalStateException: Implementation error: encountered two expressions with the same target property size
In some cases it prevents us from saving a rule, but in most cases it generates gigabytes of log messages as users simply render UI. In our most recent encounter, it seems responsible for a memory leak that eventually exhausted heap. We've submitted multiple tickets, but we always fail to escalate to the right engineer and are eventually told to "fix your code".
My question for Pega is whether it's possible to include the property names in the error output. Otherwise there is no way to debug this except searching the haystack straw by straw.
The error is typically thrown by...
java.util.Map expression_metadata = tools.getInfEngUtils().getExpressionMetadata(aTopLevelPage );
... in Harness-ConfigureExpressions while generating the client side declare expression Javascript text. We've found reliable ways to reproduce it, e.g. specialize expression ".pxListSubscript" in another class. (Someone here tried that recently because the @baseclass version wasn't firing reliably in the subclass). But almost any case of specializing an existing expression is a candidate to cause it.
Until someone can explain the core design principle we're violating, it leaves us with little choice by to gradually rip out declare expressions. (I'm afraid that given how often we're forced to pepper our code with Property.seekValue(), I'm leaning this direction anyway.)