Uh oh!
There was an error while loading. Please reload this page.
Apply workflow function transformation in "step" mode - #420
Merged
TooTallNate merged 5 commits intoNov 27, 2025
Merged
Conversation
🦋 Changeset detectedLatest commit: 0435e44 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
The latest updates on your projects. Learn more about Vercel for GitHub.
|
MemberAuthor
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Contributor
There was a problem hiding this comment.
Additional Suggestion:
Default export workflow functions are not being transformed in step mode. They should have their bodies replaced with error throws like exported named workflow functions do.
View Details
📝 Patch Details
diff --git a/packages/swc-plugin-workflow/transform/src/lib.rs b/packages/swc-plugin-workflow/transform/src/lib.rs
index 5a054fe..b0a5a17 100644
--- a/packages/swc-plugin-workflow/transform/src/lib.rs+++ b/packages/swc-plugin-workflow/transform/src/lib.rs@@ -4531,7 +4531,14 @@ impl VisitMut for StepTransform {
match self.mode {
TransformMode::Step => {
- // Workflow functions are not processed in step mode+ // In step mode, remove the directive for now+ // We'll visit children to process nested steps,+ // then replace the body with throw error afterwards+ self.remove_use_workflow_directive(+ &mut fn_expr.function.body,+ );+ self.workflow_functions_needing_id+ .push((name.clone(), fn_expr.function.span));
}
TransformMode::Workflow => {
// In workflow mode, just remove the directive
@@ -5769,7 +5776,12 @@ impl VisitMut for StepTransform {
match self.mode {
TransformMode::Step => {
- // Workflow functions are not processed in step mode+ // In step mode, remove the directive for now+ // We'll visit children to process nested steps,+ // then replace the body with throw error afterwards+ self.remove_use_workflow_directive(&mut fn_expr.function.body);+ self.workflow_functions_needing_id+ .push((const_name.clone(), fn_expr.function.span));
}
TransformMode::Workflow => {
// In workflow mode, just remove the directive
@@ -5917,6 +5929,50 @@ impl VisitMut for StepTransform {
}
decl.visit_mut_children_with(self);
++ // After visiting, process the function again for cleanup+ if let DefaultDecl::Fn(fn_expr) = &mut decl.decl {+ let is_workflow = self.workflow_function_names.contains("default");++ // In Step mode, replace workflow function body with throw after processing nested steps+ if matches!(self.mode, TransformMode::Step) {+ if is_workflow {+ // Replace workflow function body with error throw+ let const_name = self.workflow_export_to_const_name+ .get("default")+ .map(|s| s.to_string())+ .unwrap_or_else(|| "default".to_string());+ if let Some(body) = &mut fn_expr.function.body {+ let error_msg = format!(+ "You attempted to execute workflow {} function directly. To start a workflow, use start({}) from workflow/api",+ const_name, const_name+ );+ let error_expr = Expr::New(NewExpr {+ span: DUMMY_SP,+ ctxt: SyntaxContext::empty(),+ callee: Box::new(Expr::Ident(Ident::new(+ "Error".into(),+ DUMMY_SP,+ SyntaxContext::empty(),+ ))),+ args: Some(vec![ExprOrSpread {+ spread: None,+ expr: Box::new(Expr::Lit(Lit::Str(Str {+ span: DUMMY_SP,+ value: error_msg.into(),+ raw: None,+ }))),+ }]),+ type_args: None,+ });+ body.stmts = vec![Stmt::Throw(ThrowStmt {+ span: DUMMY_SP,+ arg: Box::new(error_expr),+ })];+ }+ }+ }+ }
}
_ => {
decl.visit_mut_children_with(self);
@@ -5942,7 +5998,12 @@ impl VisitMut for StepTransform {
match self.mode {
TransformMode::Step => {
- // Workflow functions are not processed in step mode+ // In step mode, remove the directive for now+ // We'll visit children to process nested steps,+ // then replace the body with throw error afterwards+ self.remove_use_workflow_directive(&mut fn_expr.function.body);+ self.workflow_functions_needing_id+ .push((const_name.clone(), fn_expr.function.span));
}
TransformMode::Workflow => {
// In workflow mode, convert to const declaration
@@ -6043,7 +6104,12 @@ impl VisitMut for StepTransform {
match self.mode {
TransformMode::Step => {
- // Workflow functions are not processed in step mode+ // In step mode, remove the directive for now+ // We'll visit children to process nested steps,+ // then replace the body with throw error afterwards+ self.remove_use_workflow_directive(&mut fn_expr.function.body);+ self.workflow_functions_needing_id+ .push((const_name.clone(), fn_expr.function.span));
}
TransformMode::Workflow => {
// In workflow mode, convert to const declaration
@@ -6137,6 +6203,88 @@ impl VisitMut for StepTransform {
}
expr.visit_mut_children_with(self);
++ // After visiting, process the function again for cleanup+ if matches!(self.mode, TransformMode::Step) {+ let is_workflow = self.workflow_function_names.contains("default");+ if is_workflow {+ match &mut *expr.expr {+ Expr::Fn(fn_expr) => {+ // Replace workflow function body with error throw+ let const_name = self.workflow_export_to_const_name+ .get("default")+ .map(|s| s.to_string())+ .unwrap_or_else(|| "default".to_string());+ if let Some(body) = &mut fn_expr.function.body {+ let error_msg = format!(+ "You attempted to execute workflow {} function directly. To start a workflow, use start({}) from workflow/api",+ const_name, const_name+ );+ let error_expr = Expr::New(NewExpr {+ span: DUMMY_SP,+ ctxt: SyntaxContext::empty(),+ callee: Box::new(Expr::Ident(Ident::new(+ "Error".into(),+ DUMMY_SP,+ SyntaxContext::empty(),+ ))),+ args: Some(vec![ExprOrSpread {+ spread: None,+ expr: Box::new(Expr::Lit(Lit::Str(Str {+ span: DUMMY_SP,+ value: error_msg.into(),+ raw: None,+ }))),+ }]),+ type_args: None,+ });+ body.stmts = vec![Stmt::Throw(ThrowStmt {+ span: DUMMY_SP,+ arg: Box::new(error_expr),+ })];+ }+ }+ Expr::Arrow(arrow_expr) => {+ // Replace arrow body with throw error+ let const_name = self.workflow_export_to_const_name+ .get("default")+ .map(|s| s.to_string())+ .unwrap_or_else(|| "default".to_string());+ let error_msg = format!(+ "You attempted to execute workflow {} function directly. To start a workflow, use start({}) from workflow/api",+ const_name, const_name+ );+ let error_expr = Expr::New(NewExpr {+ span: DUMMY_SP,+ ctxt: SyntaxContext::empty(),+ callee: Box::new(Expr::Ident(Ident::new(+ "Error".into(),+ DUMMY_SP,+ SyntaxContext::empty(),+ ))),+ args: Some(vec![ExprOrSpread {+ spread: None,+ expr: Box::new(Expr::Lit(Lit::Str(Str {+ span: DUMMY_SP,+ value: error_msg.into(),+ raw: None,+ }))),+ }]),+ type_args: None,+ });+ arrow_expr.body = Box::new(BlockStmtOrExpr::BlockStmt(BlockStmt {+ span: DUMMY_SP,+ ctxt: SyntaxContext::empty(),+ stmts: vec![Stmt::Throw(ThrowStmt {+ span: DUMMY_SP,+ arg: Box::new(error_expr),+ })],+ }));+ }+ _ => {}+ }+ }+ }
}
fn visit_mut_module_decl(&mut self, decl: &mut ModuleDecl) {
Analysis
Default export workflow functions not transformed in step mode
What fails: Workflow functions exported as default exports (e.g., export default async function defaultWorkflow() { 'use workflow'; ... }) are not having their bodies replaced with error throws in step mode, while named exports and const exports receive this transformation.
How to reproduce:
The issue is evident by comparing test fixture output files. The input file packages/swc-plugin-workflow/transform/tests/fixture/workflow-client-property/input.js contains:
exportasyncfunctionmyWorkflow(){'use workflow';// ...}exportdefaultasyncfunctiondefaultWorkflow(){'use workflow';// ...}When transformed in step mode, the named export myWorkflow correctly becomes:
exportasyncfunctionmyWorkflow(){thrownewError("You attempted to execute workflow myWorkflow function directly...");}But the default export defaultWorkflow incorrectly remains:
exportdefaultasyncfunctiondefaultWorkflow(){'use workflow';// original body unchanged}Expected behavior: The default export should also throw an error in step mode, matching the behavior of named exports. This was the intent of commit ef73dc7 "Apply workflow function transformation in 'step' mode" which updated the test fixture's expected output to show default exports throwing errors.
Root cause: The code in visit_mut_export_default_decl() (line 5771-5773) had Step mode handling that did nothing with a comment stating "Workflow functions are not processed in step mode". This was incorrect - the PR that introduced this function explicitly intended for workflow functions to throw errors in step mode. The named export handler visit_mut_export_decl() correctly implements this transformation, but the default export handler did not.
Fix implemented:
- Added Step mode handling in
visit_mut_export_default_declto remove the workflow directive and track the function for workflowId assignment - Added post-processing after visiting children to replace the function body with an error throw
- Applied the same fix to
visit_mut_export_default_exprfor arrow function default exports - Applied the same fix to variable declarations with workflow functions in
visit_mut_export_decl's Var handling - All fixes follow the same pattern used for named function exports
The transformation now properly handles all three forms of default exports:
export default async function name() { 'use workflow'; ... }export default async () => { 'use workflow'; ... }- Function expressions assigned to default export
All now correctly throw errors in step mode, consistent with named exports and const exports.
TooTallNateforce-pushed
the
11-25-apply_workflow_function_transformation_in_step_mode
branch
from
November 25, 2025 19:08
959fc02 to
f89f9f3CompareTooTallNate
marked this pull request as ready for review
November 25, 2025 20:18
TooTallNate
requested review from
Schniz, VaguelySerious, adriandlam and pranaygpNovember 25, 2025 20:18
TooTallNateforce-pushed
the
11-25-apply_workflow_function_transformation_in_step_mode
branch
from
November 25, 2025 23:03
df38802 to
c1ed746CompareContributor
There was a problem hiding this comment.
Additional Suggestion:
Metadata key-StepId mismatch for nested object properties: When object property step functions are nested inside workflow functions, their stepIds include the parent workflow name (e.g., step//input.js//example/helpers/objectStep), but the metadata keys don't (e.g., "helpers/objectStep"), causing inconsistency.
View Details
📝 Patch Details
diff --git a/packages/swc-plugin-workflow/transform/src/lib.rs b/packages/swc-plugin-workflow/transform/src/lib.rs
index c4fc27c..9c3fbf6 100644
--- a/packages/swc-plugin-workflow/transform/src/lib.rs+++ b/packages/swc-plugin-workflow/transform/src/lib.rs@@ -206,7 +206,7 @@ pub struct StepTransform {
anonymous_fn_counter: usize,
// Track object properties that need to be converted to initializer calls in workflow mode
// (parent_var_name, prop_name, step_id)
- object_property_workflow_conversions: Vec<(String, String, String)>,+ object_property_workflow_conversions: Vec<(String, String, String, Option<String>)>,
// Current context: variable name being processed when visiting object properties
#[allow(dead_code)]
current_var_context: Option<String>,
@@ -1459,6 +1459,7 @@ impl StepTransform {
parent_var_name.to_string(),
prop_key,
step_id,
+ self.current_workflow_function_name.as_ref().cloned(),
));
}
TransformMode::Workflow => {
@@ -1477,6 +1478,7 @@ impl StepTransform {
parent_var_name.to_string(),
prop_key,
step_id,
+ self.current_workflow_function_name.as_ref().cloned(),
));
}
TransformMode::Client => {
@@ -1527,6 +1529,7 @@ impl StepTransform {
parent_var_name.to_string(),
prop_key.to_string(),
step_id,
+ self.current_workflow_function_name.as_ref().cloned(),
));
}
TransformMode::Workflow => {
@@ -1536,6 +1539,7 @@ impl StepTransform {
parent_var_name.to_string(),
prop_key.to_string(),
step_id,
+ self.current_workflow_function_name.as_ref().cloned(),
));
}
TransformMode::Client => {
@@ -2651,8 +2655,12 @@ impl StepTransform {
.collect();
// Add object property step functions to metadata
- for (parent_var, prop_name, step_id) in &self.object_property_workflow_conversions {- let key = format!("{}/{}", parent_var, prop_name);+ for (parent_var, prop_name, step_id, workflow_name) in &self.object_property_workflow_conversions {+ let key = if let Some(wf_name) = workflow_name {+ format!("{}/{}/{}", wf_name, parent_var, prop_name)+ } else {+ format!("{}/{}", parent_var, prop_name)+ };
steps_entries.push(format!("\"{}\":{{\"stepId\":\"{}\"}}", key, step_id));
}
diff --git a/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-step.js b/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-step.js
index de7b584..cb77670 100644
--- a/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-step.js+++ b/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-step.js@@ -1,5 +1,5 @@
import { registerStepFunction } from "workflow/internal/private";
-/**__internal_workflows{"workflows":{"input.js":{"example":{"workflowId":"workflow//input.js//example"}}},"steps":{"input.js":{"arrowStep":{"stepId":"step//input.js//arrowStep"},"helpers/objectStep":{"stepId":"step//input.js//example/helpers/objectStep"},"letArrowStep":{"stepId":"step//input.js//letArrowStep"},"step":{"stepId":"step//input.js//step"},"varArrowStep":{"stepId":"step//input.js//varArrowStep"}}}}*/;+/**__internal_workflows{"workflows":{"input.js":{"example":{"workflowId":"workflow//input.js//example"}}},"steps":{"input.js":{"arrowStep":{"stepId":"step//input.js//arrowStep"},"example/helpers/objectStep":{"stepId":"step//input.js//example/helpers/objectStep"},"letArrowStep":{"stepId":"step//input.js//letArrowStep"},"step":{"stepId":"step//input.js//step"},"varArrowStep":{"stepId":"step//input.js//varArrowStep"}}}}*/;
// Function declaration step
async function example$step(a, b) {
return a + b;
diff --git a/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-workflow.js b/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-workflow.js
index bee6fcd..9a91339 100644
--- a/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-workflow.js+++ b/packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-workflow.js@@ -1,4 +1,4 @@-/**__internal_workflows{"workflows":{"input.js":{"example":{"workflowId":"workflow//input.js//example"}}},"steps":{"input.js":{"arrowStep":{"stepId":"step//input.js//arrowStep"},"helpers/objectStep":{"stepId":"step//input.js//example/helpers/objectStep"},"letArrowStep":{"stepId":"step//input.js//letArrowStep"},"step":{"stepId":"step//input.js//step"},"varArrowStep":{"stepId":"step//input.js//varArrowStep"}}}}*/;+/**__internal_workflows{"workflows":{"input.js":{"example":{"workflowId":"workflow//input.js//example"}}},"steps":{"input.js":{"arrowStep":{"stepId":"step//input.js//arrowStep"},"example/helpers/objectStep":{"stepId":"step//input.js//example/helpers/objectStep"},"letArrowStep":{"stepId":"step//input.js//letArrowStep"},"step":{"stepId":"step//input.js//step"},"varArrowStep":{"stepId":"step//input.js//varArrowStep"}}}}*/;
export async function example(a, b) {
var step = globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//input.js//example/step");
// Arrow function with const
Analysis
Metadata key-StepId mismatch for nested object properties in workflows
What fails: Object property step functions nested inside workflow functions generate inconsistent metadata keys. The stepId includes the workflow name (e.g., "step//input.js//example/helpers/objectStep"), but the metadata key doesn't (e.g., "helpers/objectStep"), causing a mismatch that breaks tools relying on metadata key-to-stepId matching.
How to reproduce:
- Create a workflow with nested object property step functions
- Build with the transform plugin
- Examine the
__internal_workflowsmetadata comment in output - Compare metadata keys vs stepIds for object properties
Result: In packages/swc-plugin-workflow/transform/tests/fixture/nested-step-in-workflow/output-workflow.js, the metadata shows:
"helpers/objectStep": {"stepId": "step//input.js//example/helpers/objectStep"}
The key lacks the "example/" workflow prefix that appears in the stepId.
Expected: Metadata key should be "example/helpers/objectStep" to match the hierarchical structure of the stepId when nested in a workflow.
Root cause: The object_property_workflow_conversions vector stored (parent_var_name, prop_name, step_id) but discarded the workflow name after using it to generate the stepId. Metadata generation only had access to parent_var_name and prop_name, not the workflow context.
Fix: Extended the tuple to store (parent_var_name, prop_name, step_id, workflow_name) so metadata generation can include the workflow prefix when present, matching the format used during step ID creation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Enhanced the SWC plugin to transform workflow functions in "step" mode, ensuring they throw appropriate errors when called directly.
This allows the
start()function to be used within step function to trigger new workflow runs.What changed?
This PR updates the SWC plugin to properly handle workflow functions in "step" mode:
start(functionName)insteadWhy make this change?
Previously, workflow functions in step mode weren't being transformed, which could lead to unexpected behavior when users tried to call them directly in a step function. This change ensures a consistent developer experience by providing clear error messages when workflow functions are called directly in a step function. The
workflowIdproperty is attached in "step" mode so that thestart()function may be used.