Allow providing a workpool component to use in place of the internal one

[ianmacartney]

Allow

const workpool = new Workpool(...existing workpool);

const workflow = new WorkflowManager(components.workflow, {
  workpool
});

Pass the fn handles of the pool component into the flow component, since we can't pass component handles currently

[rdubtrax]

When working with an external API with rate limiting, some of the work may be accomplished by a simple workpool but some of the work may require multiple steps and thus be a better fit for a workflow. It'd be awesome to be able to re-use the same workpool so all activity to an external API could use the same workpool

[srich36]

huge +1 to this feature

[srich36]

is defining multiple workflow components in your convex.config.ts the best way to do something like this (per-workflow concurrency control) currently?

[ianmacartney]

yes multiple workflow components works for now. I hear you on the request - hopefully some workflow bandwidth is coming soon

…

On Thu, Aug 7, 2025 at 12:28 AM Sean Rich ***@***.***> wrote: *srich36* left a comment (get-convex/workflow#34) <#34 (comment)> is defining multiple workflow components in your convex.config.ts the best way to do something like this (per-workflow concurrency control) currently? — Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQW3RNCBIPTYFJMD7Y6L3ML5YNAVCNFSM6AAAAAB2KQX7L2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNRSHA3DSNZXG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[srich36]

@ianmacartney gotcha - that workaround works! And thank you, I know there's a ton of feature requests coming your way and it's no easy feat tackling all of them 🫡

fwiw, I use convex in production already, but think fleshing out the workflow component more will be one of the biggest unlocks for making convex even more of an excellent choice for companies as they scale. And I've already recommended Convex to a bunch of founder friends!

More and more workflows for AI-native apps are shifting to be background + DAG-driven (as opposed to the old model where most actions are user initiated from a UI). I think the primitives from Convex are really uniquely positioned to thrive in this paradigm (which is why I'm so excited about the workflow component!).

Things like:

• first class support for concurrency control across tenants (e.g. max parallelism by a customerId key)
• pause + resume on workflows
• workflow observability in the dashboard with the ability to replay failed workflows (AWS step functions, hatchet.run, trigger.dev style)

would make an already amazing dev experience even better 😃

and I know dropping even more feature requests isn't particular helpful, but if there's any way I can help by dedicating any of my time to things around this let me know!

[downright-development]

Would this also allow a big opportunity to produce rollup/summaries where it ends out with emails back to users?

Example:

Cron to check for overdue items, update a flag in the DB (status == overdue if the dueDate > Date.now), then send a single summarized email to the user when complete.

I'd imagine a workflow to handle this per user, where the user may have many overdue items and wants to batch process them in a workpool, then produce the result when teh workpool has finished for that user?

[davidoort]

I would love to have something like keyed workpool / independent queues with their own parallelism limits, so i can queue steps on a Map<string, Workpool> where string could be a userId, resourceId, projectId, etc. This is especially useful in cases where for the Workpool I want maxParallelism of 1 per userId/resourceId/projectId/etc to ensure steps happen serially.

I don't think this issue describes quite that, but my request would definitely solve this issue as string could also be a workflowName. Curious if there's already a way to accomplish what i need...