### Key Changes
**Generation Settings**
- Support for `temperature`, `maxOutputTokens`, `topP`, `topK`, `presencePenalty`, `frequencyPenalty`, `stopSequences`, `seed` at constructor and per-stream level
**Step Control**
- Added `maxSteps` to limit LLM calls (default: unlimited for backwards compatibility)
- Added `toolChoice` (`auto`, `none`, `required`, or specific tool)
- Added `activeTools` to filter available tools per-stream call
**Callbacks**
- `onChunk` - called for each stream chunk
- `onStepFinish` - called after each step completes
- `onFinish` - called when all steps complete
- `onError` - called on errors
- `onAbort` - called when aborted via `AbortSignal`
**Structured Output**
- Added `experimental_output` with `Output.object({ schema })` for parsing structured responses
**Context & Telemetry**
- Added `experimental_context` to pass data to tool executions
- Added `experimental_telemetry` for observability
**Stream Result**
- `stream()` now returns `{ messages, steps, experimental_output }` instead of just `{ messages }`
**Other**
- `prepareStep` can now override generation settings, toolChoice, and context
- Added `experimental_repairToolCall` for handling malformed tool calls
- Enabled file, source, and tool input streaming chunks
- Exported all new types from `@workflow/ai`
The current implementation of suspension handler processes the invocation queue sequentially which is really slow. Now we process is in parallel:
- Process hooks first, then steps and waits in parallel to prevent race conditions
- Refactor runtime.ts into modular files: `suspension-handler.ts`, `step-handler.ts`, `helpers.ts`
- nit: Add otel attributes for hooks created (`workflow.hooks.created`) and waits created (`workflow.waits.created`)
- nit: Update suspension status from `pending_steps` to `workflow_suspended`
The `idempotency` test was running **110 concurrent steps** (10 + 100), with each step requiring multiple filesystem operations in the local world:
1. **Step creation** - writes step JSON file
2. **Step update** - reads and overwrites step JSON file
3. **Event creation** - writes event JSON file
That's ~3-4 file operations per step × 110 steps = **330-440 total file operations**.
On Windows, this is especially slow because:
- **NTFS** is slower than ext4/APFS for small file writes
- **Windows Defender** real-time scanning adds latency to new file creation
- The **atomic write pattern** (write temp file → rename) is slower on Windows
Reduced the number of steps from **110 to 20** (5 + 15 instead of 10 + 100):
**`workflows/noop.ts`**:
- First batch: 10 → 5 steps
- Second batch: 100 → 15 steps
**`src/idempotency.mts`**:
- Updated assertion to expect 20 numbers instead of 110
This is ~5.5x fewer file operations while still testing the same concurrent step execution and idempotency behavior. The test should now complete well within the 60-second timeout even on slow Windows CI machines.
* chore: use workflow health endpoint to check for port
* chore: update comment
* changeset
* Fix: The JSDoc comment for the `probePort` function is outdated and doesn't match the implementation. It claims the function returns true for "non-404 response" but the code now checks for exactly 200 status.
This commit fixes the issue reported at packages/utils/src/get-port.ts:251
## Outdated JSDoc comment in probePort() function doesn't match implementation
**What fails:** The JSDoc comment at line 251 of `packages/utils/src/get-port.ts` claims the `probePort()` function `@returns true if the port responds as a workflow server (non-404 response)`, but the actual implementation at line 269 explicitly checks `return response.status === 200;`
**How to reproduce:**
1. Read the JSDoc comment for `probePort()` function in `packages/utils/src/get-port.ts` (line 251)
2. Read the implementation at lines 268-269
3. Observe the mismatch: the comment says "non-404 response" but code checks for exactly status 200
**What happened vs expected behavior:**
- The code behavior was changed in commit `34cb235` (Dec 15, 2025) from checking `response.status !== 404` to checking `response.status === 200`
- The internal code comments were updated in commit `5840ab2`, but the JSDoc was left outdated
- Developers reading the JSDoc would incorrectly believe the function accepts any non-404 response (400, 405, etc.) when it actually requires exactly 200
**Fix:** Updated the JSDoc `@returns` line to accurately reflect the implementation: `@returns true if the port responds with a 200 status from the health check endpoint`
**Verification:** All 19 tests in `packages/utils/src/get-port.test.ts` pass with the updated documentation.
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
---------
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Nathan Rajlich