Skip to content

Conversation

@adriandlam
Copy link
Member

No description provided.

@changeset-bot
Copy link

changeset-bot bot commented Dec 3, 2025

🦋 Changeset detected

Latest commit: a5cb073

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

This PR includes changesets to release 13 packages
Name Type
@workflow/builders Patch
workflow Patch
@workflow/core Patch
@workflow/nest Patch
@workflow/astro Patch
@workflow/cli Patch
@workflow/next Patch
@workflow/nitro Patch
@workflow/sveltekit Patch
@workflow/ai Patch
@workflow/world-testing Patch
@workflow/web-shared Patch
@workflow/nuxt 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
Copy link
Contributor

vercel bot commented Dec 3, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
example-nextjs-workflow-turbopack Ready Ready Preview Comment Dec 9, 2025 5:51pm
example-nextjs-workflow-webpack Ready Ready Preview Comment Dec 9, 2025 5:51pm
example-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-astro-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-express-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-fastify-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-hono-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-nitro-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-nuxt-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-sveltekit-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workbench-vite-workflow Ready Ready Preview Comment Dec 9, 2025 5:51pm
workflow-docs Ready Ready Preview Comment Dec 9, 2025 5:51pm

Comment on lines +25 to +26
async onModuleInit() {
await enqueue(() => localBuilder.build());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Build failures during module initialization are silently swallowed due to error handling in createBuildQueue(). If the build fails at startup, the module still completes initialization successfully, causing later HTTP requests to fail with import errors instead of a clear build failure message.

View Details
📝 Patch Details
diff --git a/packages/builders/src/build-queue.ts b/packages/builders/src/build-queue.ts
index 1fe5d48..5b4e3db 100644
--- a/packages/builders/src/build-queue.ts
+++ b/packages/builders/src/build-queue.ts
@@ -20,6 +20,7 @@ export function createBuildQueue() {
   return (task: () => Promise<void>): Promise<void> => {
     queue = queue.then(task).catch((err) => {
       console.error(err);
+      throw err;
     });
     return queue;
   };

Analysis

Build failures during NestJS module initialization are silently swallowed

What fails: createBuildQueue() in packages/builders/src/build-queue.ts has a .catch() handler that logs errors but doesn't re-throw them. When the build fails during WorkflowModule.onModuleInit(), the error is swallowed and module initialization completes successfully. Later, HTTP requests to WorkflowController fail with import errors instead of a clear build failure.

How to reproduce:

  1. Create an invalid workflow that causes localBuilder.build() to throw an error
  2. Boot a NestJS application using WorkflowModule.forRoot()
  3. Observe that module initialization completes without error (despite build failure)
  4. Send an HTTP request to POST /.well-known/workflow/v1/step
  5. Request fails with import error: Cannot find module '.nestjs/workflow/steps.mjs' instead of the original build error

Result: The build error is logged to console but never propagated. Module initializes successfully. HTTP request fails with confusing import error instead of meaningful build failure message.

Expected: Build errors should be propagated during module initialization, causing the module to fail startup with a clear error message about what went wrong in the build.

Root cause: In packages/builders/src/build-queue.ts, the promise chain ends with .catch((err) => { console.error(err); }) which handles the error but doesn't re-throw it, causing the promise to resolve successfully even when the task fails. This is intentional for hot-reload scenarios but inappropriate for initialization where errors must be propagated.

Fix: Add throw err; in the catch handler to re-throw errors and allow them to propagate to callers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants