mirror of
https://github.com/vercel/workflow.git
synced 2026-09-14 19:59:43 +08:00
vercel[bot]
17c2ed7a81
The dynamic e2e tests called `start(source, …)` from the vitest runner. That
runs, but it is not the shape an app uses, and it skipped the most important
part of the feature: `dynamic.steps` has to be given *imported* step
functions, so the `.stepId` the build-time transform stamped on them is what
binds generated source to a registered step. The runner holds no handle on
those functions, so it had to look step ids up in the deployed manifest and
pass `{ stepId }` — the escape hatch, not the documented path.
The workflows are now generated inside the deployment, by fixtures in
`workflows/99_e2e.ts` (one file, symlinked into every workbench app). Each
fixture assembles source at runtime and starts it from a step with `{ steps:
{ add } }`, which is how a builder UI or an LLM-generated plan actually
reaches `start()`. The tests start the static fixture, take the dynamic
child's run id back, and assert on the child — so the same tests exercise
Vercel, local dev/prod and Postgres with no per-world branching.
Fixtures added: a plain generated workflow, one whose source suspends (the
resume delivery is the only path that reads the stored code back), and one
whose source calls a step it was not given. `getStepMetadata` goes with them
— it existed only for the manifest lookup this replaces.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Workflows Example App
Local Dev
$ vc link --repo --yes --scope uncurated-tests