workflow 5.0.0-beta.37 → 5.0.0-beta.38

package/README.md

@@ -28,22 +28,6 @@ The Workflow SDK community can be found on [GitHub Discussions](https://github.c
 
 Contributions to Workflow SDK are welcome and highly appreciated. Please use GitHub [issues](https://github.com/vercel/workflow/issues) and [discussions](https://github.com/vercel/workflow/discussions) to collaborate with the team and wider community.
 
-## Author list
-
-Workflow SDK was built by engineers at [Vercel](https://vercel.com) and the [Open Source Community](https://github.com/vercel/workflow/graphs/contributors).
-
-The initial core contributing engineers are:
-
-- Adrian Lam ([@adriandlam](https://github.com/adriandlam))
-- Dillon Mulroy ([@dmmulroy](https://github.com/dmmulroy))
-- Gal Schlezinger ([@Schniz](https://github.com/Schniz))
-- JJ Kasper ([@ijjk](https://github.com/ijjk))
-- Nathan Rajlich ([@TooTallNate](https://github.com/TooTallNate))
-- Peter Wielander ([@VaguelySerious](https://github.com/VaguelySerious))
-- Pranay Prakash ([@pranaygp](https://github.com/pranaygp))
-
-The Workflow SDK logo was designed by Cecilio Ruiz [@ceciliorz](https://x.com/ceciliorz)
-
 ---
 
 ## Security

package/docs/configuration/runtime-tuning.mdx

@@ -115,6 +115,14 @@ For example, a workflow can run a 10-minute inline step even with `WORKFLOW_REPL
 - Debug log filter with wildcards and negation.
 - Examples: `workflow:*`, `workflow:*,-workflow:telemetry:*`.
 
+## Transport
+
+### `WORKFLOW_H2_MULTIPLEX`
+
+- Default: enabled
+- On the Vercel World, lets concurrent event-log requests share one HTTP/2 connection instead of one connection per in-flight request.
+- Set `0` to send one event request per connection.
+
 ## Queue namespace
 
 ### `WORKFLOW_QUEUE_NAMESPACE`

package/docs/configuration/worlds.mdx

@@ -21,11 +21,11 @@ A [World](/docs/deploying) stores workflow state and delivers queue messages.
 
 Outside Vercel, Workflow defaults to the Local World. On Vercel, leave `WORKFLOW_TARGET_WORLD` unset for the normal case; Workflow detects the Vercel deployment and selects the Vercel World automatically.
 
-The World is selected when your app is **built**, not when it runs, and compiled into the server bundles. Detection therefore reads the build environment: `VERCEL_DEPLOYMENT_ID` when it is available, otherwise `VERCEL=1` for builds where no deployment exists yet. A dev server is never affected, because `VERCEL_ENV=development` and `NODE_ENV=development` both keep the Local World selected — including when `vercel env pull` has written `VERCEL=1` into `.env.local`.
+The World is selected when your app **runs**, from the environment of the process serving it, so changing `WORKFLOW_TARGET_WORLD` takes effect on the next start without a rebuild. Detection keys off `VERCEL_DEPLOYMENT_ID`, which Vercel sets in every deployed function and nothing else sets: with it, the Vercel World; without it, the Local World.
 
-If your build environment does not expose Vercel's system environment variables — for example a build that runs in a container of your own before uploading, or one where [system environment variables](https://vercel.com/docs/environment-variables/system-environment-variables) are disabled for the project — set `WORKFLOW_TARGET_WORLD=vercel` in the build environment. Without it, the deployment is built against the Local World and every run fails writing to a read-only filesystem. Switching this value requires a rebuild; changing it at runtime has no effect.
+Broader signals are deliberately ignored. `vercel env pull` writes `VERCEL=1` into `.env.local`, so a dev server or a production server started on your own machine sees it while running against a writable filesystem — where the Local World is the right choice. Set `WORKFLOW_TARGET_WORLD=vercel` explicitly if you want such a process to talk to the Vercel World; starting a run then fails with an error naming the missing `VERCEL_DEPLOYMENT_ID`.
 
-The mirror image applies when a build that looks like Vercel is served somewhere else: a production server started locally or in CI with an env file from `vercel env pull` has `VERCEL=1`, so it is built against the Vercel World and then has no `VERCEL_DEPLOYMENT_ID` at runtime. Starting a run in that server fails with an error saying so. To run the same code against your filesystem, set `WORKFLOW_TARGET_WORLD=local` and rebuild.
+A deployment that pins `WORKFLOW_TARGET_WORLD=local` warns at startup and fails on its first write, because a Vercel deployment's filesystem is read-only.
 
 Set `WORKFLOW_TARGET_WORLD` only when you want to use a custom or self-hosted World:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "workflow",
-  "version": "5.0.0-beta.37",
+  "version": "5.0.0-beta.38",
   "description": "Workflow SDK - Build durable, resilient, and observable workflows",
   "main": "dist/typescript-plugin.cjs",
   "type": "module",
@@ -59,18 +59,18 @@
   },
   "dependencies": {
     "ms": "2.1.3",
-    "@workflow/astro": "5.0.0-beta.37",
-    "@workflow/cli": "5.0.0-beta.37",
-    "@workflow/core": "5.0.0-beta.37",
-    "@workflow/errors": "5.0.0-beta.13",
+    "@workflow/astro": "5.0.0-beta.38",
+    "@workflow/cli": "5.0.0-beta.38",
+    "@workflow/core": "5.0.0-beta.38",
+    "@workflow/errors": "5.0.0-beta.14",
     "@workflow/typescript-plugin": "5.0.0-beta.5",
-    "@workflow/utils": "5.0.0-beta.7",
-    "@workflow/next": "5.0.0-beta.37",
-    "@workflow/nest": "5.0.0-beta.37",
-    "@workflow/nitro": "5.0.0-beta.37",
-    "@workflow/nuxt": "5.0.0-beta.37",
-    "@workflow/sveltekit": "5.0.0-beta.37",
-    "@workflow/rollup": "5.0.0-beta.37"
+    "@workflow/utils": "5.0.0-beta.8",
+    "@workflow/next": "5.0.0-beta.38",
+    "@workflow/nest": "5.0.0-beta.38",
+    "@workflow/nitro": "5.0.0-beta.38",
+    "@workflow/nuxt": "5.0.0-beta.38",
+    "@workflow/sveltekit": "5.0.0-beta.38",
+    "@workflow/rollup": "5.0.0-beta.38"
   },
   "devDependencies": {
     "@types/ms": "2.1.0",