* Disable Turborepo cache for CI related tasks
Disable cache for all tasks except "build"
* Checkout swc-plugin test fixture files with Unix newlines for Windows (#331)
* postgres: use non-deprecated drizzle signatures
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* postgres: store metadata in the hook
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* core: do not rely on module cache for world config. instead, use a global and a symbol.
this makes sure that streamers can use in-memory event emitters and that it won't be compiled away into the different flow.js and step.js files.
this was figured out when i was adding a hooks tests to world-testing.
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* add postgres world to all workbench packages
we try to run them with the postgres world but it's not installed
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* Replace jsonb with cbor because zero byte does not work in jsonb :(
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* fix error handling: attempts start at 0 now, and not 1 like when we released. so initial attempt in postgres should reflect that.
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* drain stuff
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* fallback metadata to metadataJson
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* Make code more readable
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* apply Vade fix
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
---------
Signed-off-by: Gal Schlezinger <gal@spitfire.co.il>
* Initial plan
* Fix DurableAgent to handle FatalError in tool calls
Convert FatalError exceptions in tool execution to tool-result errors that get
propagated back to the LLM, mimicking AI SDK behavior. Non-fatal errors are
re-thrown to allow workflow retry mechanisms to handle them.
- Updated executeTool to catch FatalError and convert to error-text tool result
- Added comprehensive tests for error handling scenarios
- All tests passing
Co-authored-by: pranaygp <1797812+pranaygp@users.noreply.github.com>
* Address code review feedback and add changeset
Remove unnecessary type assertion and add changeset for the DurableAgent fix
Co-authored-by: pranaygp <1797812+pranaygp@users.noreply.github.com>
* Update packages/ai/src/agent/durable-agent.ts
* Apply suggestion from @pranaygp
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: pranaygp <1797812+pranaygp@users.noreply.github.com>
Co-authored-by: Peter Wielander <mittgfu@gmail.com>
Co-authored-by: Pranay Prakash <pranay.gp@gmail.com>
Fixed a bug where default export workflow functions with names (e.g., `export default async function testWorkflow()`) would fail at runtime with `ReferenceError: $$default is not defined`. The SWC plugin now correctly keeps the default export as-is and simply adds the workflowId assignment after it, since the function name is available as a binding in the module scope.
Also adds support for anonymous and arrow function default exports, which previously were not being transformed at all.
Fixes#367.
* Fix workflow failing because of function timeouts
* Update packages/core/src/runtime.ts
Co-authored-by: Peter Wielander <mittgfu@gmail.com>
---------
Co-authored-by: Peter Wielander <mittgfu@gmail.com>
* Add e2e tests for postgres world
* Add e2e tests for postgres world
- Add new e2e-local-postgres job to test all workbenches against postgres world
- Configure PostgreSQL service container in GitHub Actions
- Update world-postgres build script to chmod +x the setup.js bin
- Use direct path to setup script in CI for reliability
- Tests run in production mode similar to e2e-local-prod tests
Made the `tools` parameter optional in the `DurableAgent` class.
### What changed?
- Updated the `DurableAgentOptions` interface to make the `tools` property optional
- Modified the constructor to initialize `this.tools` with an empty object (`{}`) when `options.tools` is not provided
Added support for defining `model` as a step function initializer in the AI workflow package.
### What changed?
- Modified the `DurableAgent` class to accept either a string model ID or a function that returns a `LanguageModelV2` instance
- Updated the `doStreamStep` function to handle both string model IDs and function initializers
- Added proper error handling for invalid model initialization arguments
### How to test?
Test both initialization methods:
1. Using a string model ID:
```typescript
const agent = new DurableAgent({
model: 'anthropic/claude-opus',
// other options
});
```
2. Using a step function initializer:
```typescript
import { xai } from "@ai-sdk/xai"
const agent = new DurableAgent({
model: async () => {
"use step";
return xai("grok-4");
},
// other options
});
```
### Why make this change?
This enhancement provides more flexibility in how language models are initialized and used within the workflow. By supporting function initializers, users can now:
- Use custom model instances with specialized configurations
- Implement more complex model initialization logic that wasn't possible with just string identifiers
Added support for nested step functions inside workflow functions, improving the SWC plugin's ability to handle complex workflow patterns.
### What changed?
- Added support for nested step functions inside workflow functions
- Implemented hoisting of nested step functions in step mode
- Added tracking of default exports that need to be replaced with expressions
- Refactored function processing logic into a dedicated `process_stmt` method
- Fixed directive detection and removal in various contexts
- Improved handling of workflow functions with both file-level and inline directives
- Added conditional body replacement for workflow functions based on directive source
- Added test cases for nested step functions in workflow functions
### How to test?
1. Create a workflow function with a nested step function:
```javascript
export async function example(a, b) {
"use workflow";
async function step(a, b) {
"use step";
return a + b;
}
const val = await step(a, b);
return val;
}
```
2. Verify the output in different modes:
- Step mode: The nested step function is hoisted to module level
- Workflow mode: The nested step function is replaced with a proxy reference
- Client mode: The workflow function throws an error when called directly
### Why make this change?
This change enables more complex workflow patterns by allowing step functions to be defined inside workflow functions. Previously, all step functions had to be defined at the module level, which limited code organization options. With this change, developers can define step functions closer to where they're used, improving code readability and maintainability while still ensuring proper transformation for all execution modes.
Added support for step functions defined as object properties in the SWC plugin.
### What changed?
This PR extends the SWC plugin to support step functions defined as object properties. It now handles three different patterns:
1. Arrow functions in object properties: `tool({ execute: async () => { "use step"; ... } })`
2. Function expressions in object properties: `tool({ execute: async function() { "use step"; ... } })`
3. Method syntax in objects: `tool({ async execute() { "use step"; ... } })`
The implementation:
- Detects "use step" directives in object property functions
- Hoists these functions in step mode
- Converts them to step initializer calls in workflow mode
- Properly tracks and registers these functions with appropriate identifiers
- Updates metadata generation to include object property step functions
### How to test?
Test with various object property function patterns:
```javascript
// Arrow function in object property
const weatherTool = tool({
execute: async ({ location }) => {
"use step";
return { location, temperature: 72 };
}
});
// Function expression in object property
const timeTool = tool({
execute: async function() {
"use step";
return { time: new Date().toISOString() };
}
});
// Method syntax
const dateTool = tool({
async execute() {
"use step";
return { date: new Date().toDateString() };
}
});
```
### Why make this change?
This change enables a common pattern in JavaScript where functions are defined as object properties, particularly in AI SDK tool definitions.
Previously, the SWC plugin only supported top-level function declarations and expressions with the `"use step"` directive. This enhancement provides a more natural developer experience by allowing step functions to be defined directly within their object context.
Replace `Symbol.for("WORKFLOW_STEP_FUNCTION_NAME")` with a standard `stepId` property for step function annotation.
### What changed?
- Replaced the use of `STEP_FUNCTION_NAME_SYMBOL` (a Symbol) with a regular `stepId` property on step functions
- Updated the serialization logic to check for the `stepId` property instead of the Symbol
- Removed the `STEP_FUNCTION_NAME_SYMBOL` constant from symbols.ts
- Updated tests to reflect this change in implementation
### Why make this change?
This more closely resembles how Workflow functions are annotated with a `workflowId` property.
Improved step function serialization by moving the function name symbol definition from the SWC plugin to the runtime.
### What changed?
- Modified `createUseStep` in `packages/core/src/step.ts` to accept a `stepFunctionName` parameter and apply both the name property and the `WORKFLOW_STEP_FUNCTION_NAME` symbol directly to the step function at creation time
- Removed the code in the SWC plugin that was previously responsible for adding the `WORKFLOW_STEP_FUNCTION_NAME` symbol to step functions
- Updated all test outputs to reflect the removal of the redundant symbol definition code
### How to test?
1. Run the existing test suite to ensure all tests pass
2. Create a workflow with step functions and verify that:
- Step functions maintain their original function names
- Step functions have the `WORKFLOW_STEP_FUNCTION_NAME` symbol properly attached
- Serialization and deserialization of step functions works correctly
### Why make this change?
This change improves the architecture by:
1. Moving the responsibility for defining step function metadata to the runtime where it belongs
2. Ensuring step functions maintain their original names, which helps with debugging and error messages
3. Reducing redundancy by defining the symbol in one place instead of having the SWC plugin generate it for each function
4. Making the code more maintainable by centralizing the step function creation logic
- Modified SWC plugin to convert exported step functions to const declarations
- Instead of wrapping functions (calling useStep on every invocation), functions are now assigned directly to the result of useStep() call
- This ensures useStep() is called only once at module initialization, improving performance
- Applies to both file-level and function-level 'use step' directives
- All step function exports now use pattern: export const fn = globalThis[Symbol.for('WORKFLOW_USE_STEP')](stepId, fnName)
- Updated all test fixtures to reflect the new transformation
Signed-off-by: Nathan Rajlich <n@n8.io>
* Normalize Workbenches
Normalize trigger scripts across workbenches
fix: include hono in local build test
test: include src dir for test
test: add workflow dir config in test to fix sveltekit dev tests
add temp 7_full in example wokrflow
format
fix(sveltekit): detecting workflow folders and customizable dir
Remove 7_full and 1_simple error
replace API symlink in webpack workbench
Fix sveltekit and vite tests
Fix sveltekit symlinks
Test fixes
Fix sveltekit workflows path
Dont symlink routes in vite
Include e2e tests for hono and vite
fix error tests post normalization
wip - attempted fixes
* Add claude demo command
* fix: normalize workbench tests (#292)
* Proper stacktrace propogation in world
Proper stacktrace propogation in world
* Standardize the error type in the world spec
* Normalize Workbenches
Normalize trigger scripts across workbenches
fix: include hono in local build test
test: include src dir for test
test: add workflow dir config in test to fix sveltekit dev tests
add temp 7_full in example wokrflow
format
fix(sveltekit): detecting workflow folders and customizable dir
Remove 7_full and 1_simple error
replace API symlink in webpack workbench
Fix sveltekit and vite tests
Fix sveltekit symlinks
Test fixes
Fix sveltekit workflows path
Dont symlink routes in vite
Include e2e tests for hono and vite
* fix error tests post normalization
* fix(sveltekit): reading file on hmr delete
* changeset
* fix(vite): add resolve symlink script
* fix(vite): missing building on hmr
* test local builder in vite
* test: increase timeout on hookWorkflow
* test: ignore vite based apps in crossFileWorkflow
* test: fix nitro based apps status codes
* fix: intercept default vite spa handler on 404 workflow routes
* fix: vite hook route returning 422
* test: use 422 for hookWorkflow expected
* test: fix hono returning 404
* chore: add comment to middleware to clarify
* make api route for duplicate case
* revert
* revert: nitro builder
* add back nitro unhandled rejection logic
* test: add hono
* changeset
* fix: unused method
* fix: remove duplicate import
* remove
* chore: add comments to clarify
* test remove vite symlink script
---------
Co-authored-by: Pranay Prakash <pranay.gp@gmail.com>
* refactor: add top level resolve symlinks script
* fix: cleanup builder directories (#319)
* fix: add sveltekit server routes to builder
* fix: remove root workflow dir check
* fix missing root level workflow route
* Fix: The constructor now hardcodes `dirs: ['src/routes', 'src/lib']` which silently ignores any user\-provided `dirs` option passed to the plugin\, breaking the documented API and removing support for custom workflow directories\.
* Fix: The test expectations don\'t match the new implementation of `getWorkflowDirs()`\. The mock provides `scanDirs` which the new code no longer uses\, and the new implementation adds scanning of `routesDir` and `apiDir` instead\.
* fix(nitro): use src dir
---------
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
* refactor(nitro): use suppressUndefinedRejections
* revert: sveltekit builder
---------
Co-authored-by: Adrian <me@adriandlam.com>
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
Vercel Release Bot