Skip to content

[Bug]: [workflow-engine-redis] Options type declares top-level redisUrl but loader only reads nested options.redis #16697

Description

@lovehubbox-cell

Package.json file

## Bug report

**Medusa version:**2.19.0 and 2.20.0 (still present)

**Files involved:**
- Type declaration: `packages/modules/workflow-engine-redis/src/types/index.ts`
- Runtime loader: `packages/modules/workflow-engine-redis/src/loaders/redis.ts`

**Describe the bug**

`RedisWorkflowsOptions` is applied via module augmentation to the *top-level*
module options:

    declare module "@medusajs/types" {
      interface ModuleOptions {
        "@medusajs/workflow-engine-redis": RedisWorkflowsOptions
        "@medusajs/medusa/workflow-engine-redis": RedisWorkflowsOptions
      }
    }

So TypeScript accepts:

    options: { redisUrl: "redis://..." }

But the runtime loader only destructures the nested object:

    } = options?.redis as RedisWorkflowsOptions
    // const resolvedUrl = redisUrl ?? url

Top-level `redisUrl`/`url` are never read. The config passes type-checking
but is silently ignored at runtime, and the loader throws:

    No `redis.redisUrl` (or deprecated `redis.url`) provided in
    `workflowOrchestrator` module options.

**Additional context:** the docs page is internally inconsistent for the same
reason — the example uses `options.redis.redisUrl` (matches runtime), while
the options table documents the top-level shape from the type declaration:
https://docs.medusajs.com/resources/infrastructure-modules/workflow-engine/redis

**Expected behavior:** types and runtime should describe the same shape —
either the augmentation should reflect the nested `redis` object, or the
loader should also accept top-level `redisUrl` for consistency with other
infrastructure modules (event-bus-redis, cache-redis). The docs options table
should then match.

Node.js version

v26

Database and its version

PostgreSQL16.3

Operating system name and version

windows 11

Browser name

Chrome

What happended?

There's an inconsistency on the official Workflow Engine page: the example uses options.redis.redisUrl, but the options table on the same page uses the top-level options.redisUrl, stating that redisUrl is a v2.12.2+ field. I will use my local 2.19.0 package type and runtime code as the final source of truth to verify this discrepancy. Please help me investigate this issue.

Expected behavior

There's an inconsistency on the official Workflow Engine page: the example uses options.redis.redisUrl, but the options table on the same page uses the top-level options.redisUrl, stating that redisUrl is a v2.12.2+ field. I will use my local 2.19.0 package type and runtime code as the final source of truth to verify this discrepancy. Please help me investigate this issue.

Actual behavior

There's an inconsistency on the official Workflow Engine page: the example uses options.redis.redisUrl, but the options table on the same page uses the top-level options.redisUrl, stating that redisUrl is a v2.12.2+ field. I will use my local 2.19.0 package type and runtime code as the final source of truth to verify this discrepancy. Please help me investigate this issue.

Link to reproduction repo

There's an inconsistency on the official Workflow Engine page: the example uses options.redis.redisUrl, but the options table on the same page uses the top-level options.redisUrl, stating that redisUrl is a v2.12.2+ field. I will use my local 2.19.0 package type and runtime code as the final source of truth to verify this discrepancy. Please help me investigate this issue.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions