Fix ArrayIndexOutOfBoundsException in failureWorkflow parameter parsing

[mohammaddanishali-bit]

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• WHOSUSING.md
• Other (please describe):

Changes in this PR

Problem

When a workflow fails and has a failureWorkflow configuration that uses
parameter substitution (e.g., "$.workflow.paramName"), the code splits
the string by "." and directly accesses array index [2] without validating
the array length first.

If the failureWorkflow is misconfigured with an invalid format such as:

• "$.input" (only 2 components)
• "$" (only 1 component)
• Any other malformed expression

This results in an ArrayIndexOutOfBoundsException at runtime, causing
the workflow termination process to fail unexpectedly.

Location: WorkflowExecutorOps.java, line 1636-1637

Root Cause

if (failureWorkflow.startsWith("$")) {
    String[] paramPathComponents = failureWorkflow.split("\\.");
    String name = paramPathComponents[2]; // No bounds checking!
    failureWorkflow = (String) workflow.getInput().get(name);
}

The code assumes the split operation always produces at least 3 elements
but provides no validation for this assumption.

Solution

Added array length validation before accessing index [2]:

1. Check if paramPathComponents.length < 3
2. If invalid: log a warning with expected format and set to null
3. If valid: proceed with existing logic

The null value is handled gracefully by the downstream terminateWorkflow()
method, which uses StringUtils.isBlank() to check before attempting to
start a failure workflow.

Describe the new behavior from this PR, and why it's needed

1. Prevents Production Crashes

• Eliminates a potential runtime exception that could disrupt workflow
  termination
• Ensures workflows can complete their termination process even with
  misconfigured failure workflows

2. Improves Error Handling

• Provides clear, actionable warning message to operators
• Makes it immediately obvious what the correct format should be
• Logs the invalid value for debugging purposes

3. Enhances System Robustness

• Follows defensive programming principles
• Validates assumptions before array access
• Degrades gracefully when encountering invalid configuration

4. Better Developer Experience

• Configuration errors are caught and reported clearly
• Reduces time spent debugging cryptic ArrayIndexOutOfBoundsException
  stack traces
• Expected format is documented in the warning message

5. Maintains Backward Compatibility

• No changes to public APIs
• Existing valid configurations continue to work identically
• Only adds validation for edge cases that would have failed anyway

Testing

Added comprehensive test case:

• testTerminateWorkflowWithInvalidFailureWorkflowFormat()
• Tests invalid format "$.input" (2 components instead of 3)
• Verifies no exception is thrown
• Confirms workflow terminates successfully
• Existing test testTerminateWorkflowWithFailureWorkflow() still passes

Impact

• Risk Level: Low - Only adds validation, no logic changes
• Affected Code Path: Workflow termination with parameterized
  failureWorkflow
• Performance: Negligible - One array length check
• Breaking Changes: None