Greptile Summary

This PR reverts error handling changes in the WorkflowBlockHandler to address intermittent issues where child workflow errors weren't being properly surfaced to parent workflows. The change fundamentally shifts from a throw-based error propagation model to a return-based error handling approach.

The main modifications involve:

• Removing explicit error throwing for failed child workflows (lines 115-118) that previously checked if success === false and threw errors with enhanced messages
• Changing the catch block behavior (lines 119-136) to return structured error objects instead of throwing exceptions
• Eliminating duplicate error message logic that was apparently causing formatting issues in nested workflows

This change aligns the workflow block error handling with the existing pattern in mapChildOutputToParent method, which already returns structured error objects rather than throwing. The WorkflowBlockHandler manages child workflow executions within parent workflows, and this change ensures that error information flows consistently through the execution chain without getting lost in exception handling complexities.

The execution stack cleanup logic remains intact, ensuring that failed child workflow executions are properly removed from the tracking system. The structured error response includes success status, error message, and child workflow name for debugging purposes.

Confidence score: 3/5

• This PR introduces significant architectural changes to error handling that could mask critical failures by treating them as successful executions containing error data
• Score reflects concerns about changing core error propagation behavior without comprehensive testing coverage, as only manual testing was performed
• Pay close attention to workflow-handler.ts and ensure thorough testing of nested workflow error scenarios before merging

_{1 file reviewed, 2 comments}

_{Edit Code Review Bot Settings | Greptile}