## Summary
- Adds `World.getEncryptionKeyForRun(run)` returning `Uint8Array | undefined` as the interface for retrieving per-run encryption keys
- Updates all 8 dehydrate/hydrate serialization functions to accept `key: Uint8Array | undefined`
- Updates runtime callers, CLI, and tests to thread the key parameter through
* Remove "workflow/internal/serialization" export
Was only being used in these two e2e test files and the data being passed in those tests don't rely on any specialized data types, so just use JSON there.
* Fix: Removing the `workflow/internal/serialization` export from package.json breaks 5 files in `packages/world-testing` that still import `hydrateWorkflowReturnValue` from that path.
Co-authored-by: TooTallNate <n@n8.io>
* lockfile
---------
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
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.
Nathan Rajlich