standardize output

[ctate]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
workflow-builder	Ready	Preview	Comment	Dec 8, 2025 6:09pm

[vercel]

Additional Suggestion:

The workflow executor incorrectly handles error objects returned by steps. When a step returns { success: false, error: { message: string } }, the code casts it to expect error?: string and directly assigns the object to the result's error field, causing the error object to be stored instead of the error message string.

View Details

📝 Patch Details

diff --git a/lib/workflow-executor.workflow.ts b/lib/workflow-executor.workflow.ts
index d5f8469..329fea1 100644
--- a/lib/workflow-executor.workflow.ts
+++ b/lib/workflow-executor.workflow.ts
@@ -586,12 +586,18 @@ export async function executeWorkflow(input: WorkflowExecutionInput) {
           (stepResult as { success: boolean }).success === false;
 
         if (isErrorResult) {
-          const errorResult = stepResult as { success: false; error?: string };
+          const errorResult = stepResult as {
+            success: false;
+            error?: string | { message: string };
+          };
+          const errorMessage =
+            typeof errorResult.error === "string"
+              ? errorResult.error
+              : errorResult.error?.message ||
+                `Step "${actionType}" in node "${node.data.label || node.id}" failed without a specific error message.`;
           result = {
             success: false,
-            error:
-              errorResult.error ||
-              `Step "${actionType}" in node "${node.data.label || node.id}" failed without a specific error message.`,
+            error: errorMessage,
           };
         } else {
           result = {

Analysis

Error object not extracted properly in workflow executor

What fails: lib/workflow-executor.workflow.ts (lines 588-595) incorrectly casts step result errors to error?: string when plugins return the standardized format error?: { message: string }, causing error objects to be stored instead of error message strings.

How to reproduce: Run any workflow that uses plugins like Clerk, Perplexity, FAL, etc. that return errors in the format:

{ success: false, error: { message: "Something failed" } }

Result: The error object { message: "..." } is stored in result.error instead of the message string. This causes type mismatch where result.error is an object instead of the expected string type, breaking error reporting when the error is accessed at line 709: error: Object.values(results).find((r) => !r.success)?.error.

Expected behavior: The error message string should be extracted and stored in result.error. The fix detects whether errorResult.error is a string or an object with a message property, extracting the message appropriately to maintain type consistency with the ExecutionResult type which defines error?: string.

Fix applied: Modified lines 588-600 to check the error type and extract the message:

• If error is a string, use it directly
• If error is an object with a message property, extract the message
• Otherwise, use the fallback error message