feat(world): add optional getMany() for batch run reads

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)

[joeyhotz]

Description

Add optional world.runs.getMany() for one-operation snapshots of multiple workflow runs. It lets GraphQL list resolvers and bulk orchestration fetch many run snapshots in a single storage call, avoiding N+1 reads.

Results preserve input order, fetch duplicate IDs once, and use null for missing runs. getMany remains optional so existing community Worlds are source-compatible.

local/vercel: delegate to the per-ID runs.get handler via Promise.all, sharing the same read, schema validation, resolveData, and error handling.

postgres: uses a single IN (...) query for an indexed batch read.

How did you test your changes?

• pnpm --filter @workflow/world-local test — 465 tests pass, including order, duplicate-ID, missing-ID, and metadata-only getMany coverage.
• pnpm --filter @workflow/world-postgres exec vitest run test/storage.test.ts --testNamePattern getMany — Postgres integration coverage passes for result mapping and a single-query assertion with duplicate IDs.
• pnpm --filter @workflow/world-vercel test — 295 tests pass, including MockAgent coverage of individual GET delegation with duplicate-ID deduplication and missing-run null handling.

PR Checklist - Required to merge

• 📦 pnpm changeset was run with minor changesets for @workflow/world, @workflow/world-local, @workflow/world-postgres, and @workflow/world-vercel.
• 🔒 DCO sign-off passes.
• 📝 Ping @vercel/workflow in a comment once the PR is ready, and the above checklist is complete.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5cec417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/world-vercel	Minor
@workflow/cli	Patch
@workflow/core	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
workflow	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

@joeyhotz is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[joeyhotz]

@vercel/workflow Ready for review. The PR follows the template; its remaining dependency is the paired workflow-server batch endpoint described above.

[VaguelySerious]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

[joeyhotz]

@joeyhotz Can you speak more to the motivation here? Is this useful for more than simply reducing request count over e.g. Promise.all([world.runs.get, ...])? If not, in what cases would the request count be an issue?

Hi @VaguelySerious. We're migrating from inngest to workflow sdk with the Postgres world. During the migration we decided to lean hard on the workflow sdk for storing and managing state. We have a graphql API. The reason why we need a batch fetch is we want to reduce the number of trips to the DB.

Think if you have a table of 25 entities that have a running job/previous job run behind it. For each entity you want to read the job timestamp or the job status (if it's running, or failed). We want to put this job status fetch in a data loader so the db read for the whole table is done in one trip, not 25.

[VaguelySerious]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

[joeyhotz]

@joeyhotz I can see how this would reduce trips to the DB, and I'm mainly trying to assess what the actual performance impact is before adding a new method to the world interface for something that might have negligible impact for most users. Have you tried a Promise.all(...world.runs.get) and measured that against a tarball of this branch?

@VaguelySerious Ran a comparison locally with a local psql db here:

// Concurrent, but still N database queriesawaitPromise.all(runIds.map((id)=>world.runs.get(id,{resolveData: 'none'})));

// One database queryawaitworld.runs.getMany!(runIds,{resolveData: 'none'});

Run IDs	Promise.all(runs.get)	getMany
25	25 queries, 1.69 ms	1 query, 0.98 ms
100	100 queries, 5.15 ms	1 query, 1.85 ms

Promise.all still checks out one connection/query per run ID. With a 10-connection pool, 100 run reads compete with normal API traffic and execute in roughly ten pool waves. getMany uses one connection for one indexed IN (...) query.

I think the performance benefit will be higher in a remote environment too.

[joeyhotz]

@VaguelySerious I'm new to the sdk so forgive me if I come across as naive, maybe another option is adding an ID filter to the list interface?

[VaguelySerious]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

[joeyhotz]

Alright, we're good with shipping this, could you make one more update? world-local and world-vercel implementations duplicate some code from the runs.get handler internally. Since they essentially just Promise.all the same code, would you be able to re-use runs.get internally for those Worlds? Let me know if that doesn't make sense

@VaguelySerious makes sense! Have pushed the changes 👍

[joeyhotz]

pinging @vercel/workflow

[VaguelySerious]

Sorry, merging is blocked on "Commits must have verified signatures". Would you be able to sign your commits and force-push?

[joeyhotz]

@VaguelySerious sorry, should be good now! thank you. not sure if i need to keep pinging @vercel/workflow but i will anyway

[github-actions]

Backport PR opened against stable: #2958. Merge conflicts were resolved by AI — please review carefully. (backport job run)