no-nested-when-in-workflow - ESLint plugin rules

This rule disallows calling when(...) inside a when().then() callback in a workflow composition function.

Severity#

error. This rule is enabled in the recommended preset.

What it Targets#

This rule targets when(...) calls that appear inside the callback of another when().then() call within a createWorkflow body.

The following code is reported by the rule:

import {
  createWorkflow,
  when,
  WorkflowResponse,
} from "@medusajs/framework/workflows-sdk"

createWorkflow("my-workflow", (input) => {
  const result = when({ input }, (d) => d.input.items.length > 0).then(() => {
    // Reported: `when` nested inside another `when().then()` callback
    const inner = when({ input }, (d) => d.input.flag).then(() => someStep(input))
    return inner
  })

  return new WorkflowResponse(result)
})

Instead, restructure the logic into sibling when(...).then(...) calls at the same level:

import {
  createWorkflow,
  when,
  WorkflowResponse,
} from "@medusajs/framework/workflows-sdk"

createWorkflow("my-workflow", (input) => {
  const result = when({ input }, (d) => d.input.items.length > 0).then(() =>
    outerStep(input)
  )

  const inner = when({ input }, (d) => d.input.items.length > 0 && d.input.flag)
    .then(() => someStep(input))

  return new WorkflowResponse(result)
})

Why it's Important#

when tracks its pending condition in a single shared slot rather than a stack. When you nest a when(...) call inside a when().then() callback, the inner .then() clears that shared slot before the outer .then() reads it. This causes a TypeError: Cannot read properties of undefined (reading 'steps') at server boot rather than at build time, making the bug difficult to trace.

Learn more in the Conditions in Workflows documentation.

Fixable#

This rule isn't auto-fixable.