Preserving RuleException in Nested Validation Flows

In a complex setup, a screen validation rule uses the AS:LookupValue function. The referenced lookup calls a workflow method, which then fails due to a RuleException (e.g., a validation error). However, on the frontend, instead of displaying the specific validation message, the user only sees a generic error:

“An error has occurred. There may be some details in the log file.”

This happens because during exception propagation, the original RuleException is wrapped or substituted by an OrigamException. The frontend interprets OrigamException as a system-level error and suppresses the detailed validation message.

If the original RuleException were preserved and delivered to the frontend, the UI would correctly display the validation error to the user.

Suggestion
Ensure that RuleException is not swallowed or replaced during exception propagation—even in this nested setup. Instead, propagate it as-is to allow the frontend to present meaningful validation feedback.