Summary
This PR adds BullMQ queue and worker configuration options to the workflow-engine-redis module, bringing feature parity with the event-bus-redis module. It also introduces per-queue
configuration options for fine-grained control over the three internal queues (main, job, and cleaner).
Key changes:
- Added per-queue BullMQ configuration options (mainQueueOptions, jobQueueOptions, cleanerQueueOptions and their worker counterparts) with shared defaults
- Unified Redis option naming across modules: deprecated url → redisUrl, options → redisOptions (with backward compatibility)
- Moved configuration resolution to the loader and registered options in the DI container
- Added comprehensive JSDoc documentation for all configuration options
- Added unit tests for option merging and queue/worker configuration
Configuration Example
```ts
// Simple configuration - same options for all queues
{
redisUrl: "redis://localhost:6379",
queueOptions: { defaultJobOptions: { removeOnComplete: 1000 } },
workerOptions: { concurrency: 10 }
}
```
```ts
// Advanced configuration - per-queue overrides
{
redisUrl: "redis://localhost:6379",
workerOptions: { concurrency: 10 }, // shared default
jobWorkerOptions: { concurrency: 5 }, // override for scheduled workflows
cleanerWorkerOptions: { concurrency: 1 } // override for cleanup (low priority)
}
```
## Summary
**What** — What changes are introduced in this PR?
Show correct color indicator for payment and fulfillment status columns when `view_configuration` feature flag is enabled on order data table.
**Why** — Why are these changes relevant or necessary?
For non canceled status, grey default indicator was shown, as these columns weren't handled with their dedicated helper functions.
**How** — How have these changes been implemented?
Updated `StatusRenderer` to resolve the label and color for these columns with their helper functions, just like we do for the normal order table.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Validated Admin UI shows correct color indicators when `view_configuration` is enabled.
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [x] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
closes CORE-1309
* chore(): Run some commands in server mode only
* Create orange-timers-lay.md
* chore(): Run some commands in server mode only
* chore(): Run some commands in server mode only
* chore(): Run some commands in server mode only
## Summary
**What** — What changes are introduced in this PR?
Improve fully refunded order details in the order list of Admin UI.
**Why** — Why are these changes relevant or necessary?
Fully refunded orders did not show a value for the `total` column and its `payment_status` color badge expressed a happy path.
**How** — How have these changes been implemented?
Added the refund amount with line through style for fully refunded orders in the `total` column of order list table and changed the `payment_status` badge color to red
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Validated UI looks as expected
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [x] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
---
> [!NOTE]
> Show refunded amounts with muted strikethrough in the total column for fully refunded orders and set the refunded payment badge to red, fetching `payment_collections` as needed.
>
> - **Admin Dashboard — Order List**:
> - **Total column**: For `payment_status === "refunded"`, display the sum of `payment_collections.refunded_amount` with `text-ui-fg-muted` and `line-through` via `TotalCell` `className`.
> - **Payment status**: Change `refunded` badge color to red.
> - **Component**: `TotalCell` now accepts optional `className`.
> - **Data**:
> - Add `*payment_collections` to `DEFAULT_RELATIONS` for orders.
> - **Changeset**:
> - Patch release for `@medusajs/dashboard`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 802d24330bceaeba74e11d85886593809876cd8d. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
> [!NOTE]
> Adds a configurable concurrency for link migrations (CLI/commands), forces concurrency=1 when pgstream is detected, and ignores duplicate link-table inserts.
>
> - **CLI**
> - Add `--concurrency` option to `db:migrate` and `db:sync-links`.
> - **Medusa commands**
> - `migrate` and `sync-links` accept `concurrency`; set `DB_MIGRATION_CONCURRENCY` and force `1` when `pgstream` schema exists via new `isPgstreamEnabled`.
> - **Link Modules (migrations)**
> - Execute plan actions with `executeWithConcurrency` using `DB_MIGRATION_CONCURRENCY`.
> - Make link-table tracking inserts idempotent with `ON CONFLICT DO NOTHING` (including bulk/upsert and per-create).
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 07432293c8fe8de30b07920fa47823b9081edacc. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
* fix(): event emitting
* Create rude-queens-deny.md
* fix(): store subscriber should not be constraint
* Update rude-queens-deny.md
* Add tests to prevent regression
* fix(fulfillment): make relationship between SO and SO type M:1
* fix: test and types, remap type id to existing column
* Fix typo
* Fix typo
* chore: update changeset
* fix: typo
---------
Co-authored-by: Nicolas Gorga <62995075+NicolasGorga@users.noreply.github.com>
## Summary
**What** — What changes are introduced in this PR?
Avoid creating reservations when draft order edits are confirmed and rather, create them when the draft order is converted into a regular order.
**Why** — Why are these changes relevant or necessary?
While the order is a draft, creating reservations would potentially block inventory for regular order requests, when the draft represents a non materialized state of a purchase that might never be completed or at a latter point in time.
**How** — How have these changes been implemented?
Removed the reservation creations inside of `confirmDraftOrderEditWorkflow` and instead do it inside `convertDraftOrderWorkflow`
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Added integration tests.
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [x] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [x] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
fixes#13773
closes SUP-2523
## Summary
**What** — What changes are introduced in this PR?
- Add HTTP type for update order API route payload + use it in the JS SDK and API route
- other: add `since` tag
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [ ] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [ ] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
* feat: carry over promotions toggle on exchanges
* fix: inital flag value, return the flag on preview
* fix: validation of allocation type
* fix: revert client changes
* fix: invert condition
* feat: recompute adjustments when outbound item is updated
* fix: condition again
* fix: display more accurate inbound/outbound totals for exchanges
* fix: make exchanges specs green
* feat: more testing cases
* wip: pr feedback
* fix: use plural for the flag on Admin
* fix: schema test, route refactor
* feat: tooltip
* feat: refactor to use update workflow
* feat: display applied promotion per item on order details, show copy sku on hover
* feat: refactor edits and exchanges to have common flag toggle flow
* fix: delete empty file
* fix: exchange_id param query
## Summary
**What** — What changes are introduced in this PR?
Display a tootlipt on line items when creating OrderEdit/Exchange to show which promotions are applied on the items.
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
<img width="786" height="910" alt="Screenshot 2025-11-25 at 14 11 22" src="https://github.com/user-attachments/assets/644bea00-b8ab-4a70-9a43-7c912ac21208" />
<img width="775" height="792" alt="Screenshot 2025-11-25 at 14 23 26" src="https://github.com/user-attachments/assets/ed935dad-9c2b-4ebd-8b9f-00d929add1ff" />
FIXES https://github.com/medusajs/medusa/issues/13976
**What**
Before applying the sales channel link filter, check if there is a single sales channel or many, if will add a bit of overhead but marginal compare to the improvement for big catalog with single sales channel
---
> [!NOTE]
> Optimizes store products listing by conditionally skipping sales channel link filtering when the index can be used or only one sales channel exists.
>
> - **Store API – `products`** (`packages/medusa/src/api/store/products/middlewares.ts`):
> - Adds `applyMaybeLinkFilterIfNecessary` middleware:
> - Skips link filtering when `IndexEngine` is enabled and no tag/category filters are present.
> - Queries `sales_channels` count; if only one exists, removes `sales_channel_id` filter and proceeds.
> - Integrates this middleware into `GET /store/products` before default filters; `GET /store/products/:id` remains unchanged with `maybeApplyLinkFilter`.
> - **Release**:
> - Adds patch changeset for `@medusajs/medusa`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 8a0b024ea1bc9696f350f34fa77df321e5ecf553. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
* Lock markFulfillmentAsDeliveredWorkflow with fulifllment id
* Lock markOrderFulfillmentAsDeliveredWorkflow by orderId before calling markFulfillmentAsDeliveredWorkflow
* Add changeset
* wip
* add wip
* wip
* reuse action
* finish first draft
* fix tests
* cleanup
* Only compute adjustments when necessary
* Create hot-carrots-look.md
* address comments
* minor tweaks
* fix pay col
* fix test
* wip
* Dwip
* wip
* fix: adjustment typo
* fix: import
* fix: workflow imports
* wip: update test
* feat: upsert versioned adjustments when previewing order
* fix: revert unique codes change
* fix: order spec test with versioning
* wip: save
* feat: make adjustments work for preview and confirm flow, wip base repo filtering of older version adjustments
* fix: missing populate where
* wip: populate where loading versioned adjustments
* fix: filter out older adjustment versions
* temp: comment adjustments in repo
* test: add adjustment if no version
* wip: configure populate where in order base repository
* fix: rm manual filtering
* fix: revert base repo changes
* fix: revert
* fix: use order item version instead of order version
* fix: rm only in test
* fix: update case spec
* fix: remove sceanrio, wip test with draft promotion
* feat: test correct adjustments when disabling promotion
* feat: complex test case
* feat: test consecutive order edits
* feat: 2 promotions test case with a fixed promo
* feat: migrate existing order line item adjustments to order items latest version
* feat: update dep after merge
* wip: load adjustments separatley
* feat: adjustments collections
* fix: spread result, handle related entity case
* fix: update lock
* feat: make sure version is loaded, refactor, handle related entity case
* fix: check fields
* feat: loading adjustments for list and count
* fix: correct items version field
* fix: rm empty array
* fix: wip order modules spec
* fix: order module specs
* feat: preinit items adjustments
* fix: rm only
* fix: rm only
* chore: cleanup
* fix: migration files
* fix: dont change formatting
* fix: core package build
* chore: more cleanup
* fix: item update util
* fix: duplicate import
* fix: refresh adjustments for exchanges (#13992)
* wip: exchange adjustments
* feat: test - receive items
* feat: finish test case
* fix: casing
* fix(draft-orders, core-flows, orders) refresh adjustments for draft orders (#14025)
* wip: draft orders adjustments refresh
* feat: rewrite to use REPLACE action + test
* fix: rm only
* feat: cleanup old REPLACE actions
* feat: cleanup adjustemnts when 0 promotions
* wip: canceling draft order
* fix: make version arg optional
* fix: restore promotion links
* feat: test reverting on cancelation
* fix: address comments in tests
* wip: fix summary on preview
* fix: get pending diff on preview summary from total
* fix: revert pending diff change
---------
Co-authored-by: fPolic <mainacc.polic@gmail.com>
Co-authored-by: Frane Polić <16856471+fPolic@users.noreply.github.com>
## Summary
**What** —
Add a providerData field to notifications
**Why** —
We need the ability to pass dynamic fields to specific providers. E.g. CC and BCC for emails
**How** —
Just adding the field to the model
**Testing** —
Added the field to existing tests
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [x] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
> [!NOTE]
> Adds `provider_data` to notifications (types, workflow input, DB model/migration) and forwards it in the Medusa Cloud Email provider, with tests updated accordingly.
>
> - **Data/Schema**:
> - Add `provider_data` (`jsonb`) to `notification` model and DB via migration `Migration20251121150408` and snapshot update.
> - **Types/DTOs**:
> - Add optional `provider_data` to `CreateNotificationDTO`, `NotificationDTO`, and `ProviderSendNotificationDTO`.
> - **Workflows**:
> - Extend `send-notifications` step input with `provider_data`.
> - **Providers**:
> - Medusa Cloud Email: include `provider_data` in outgoing request payload.
> - **Tests**:
> - Update integration tests to pass and assert `provider_data` propagation.
> - **Changeset**:
> - Patch bumps for `@medusajs/notification`, `@medusajs/core-flows`, `@medusajs/types`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 6f114c75c974a145ef60213637d7c41bc605a0bf. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
## Summary
**What** — What changes are introduced in this PR?
This pull request adds support for OXXO payments to the Stripe payment provider module. The main changes include the addition of a new `OxxoProviderService`, updates to type definitions to support OXXO-specific options, and integration of the new service into the provider's exports and registration.
**Why** — Why are these changes relevant or necessary?
I was testing the MedusaJs server, I live in México and here oxxo as a Payment method is very used.
**How** — How have these changes been implemented?
* Introduced `OxxoProviderService` in `stripe-oxxo.ts`, which extends `StripeBase` and configures Stripe payment intents for OXXO, including expiration settings.
* Updated `StripeOptions` and `PaymentIntentOptions` types to include `oxxoExpiresDays` and OXXO-specific payment method options for intent configuration.
* Added `OXXO` to the `PaymentProviderKeys` enum for provider identification.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
You need to launch the medusa server, add Stripe OXXO as Payment Provider in your Store Region (OXXO only works in México and with mxn currency) and set payment_method_data type to oxxo.
Also you need to allow oxxo payment as payment method in stripe and configure your stripe webhook to your medusa server
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage using nextjs starter
const confirmParams: any = {
return_url: returnUrl,
}
if (isOxxo(providerId)) {
confirmParams.payment_method_data = {
type: "oxxo",
billing_details: {
name:
cart.billing_address?.first_name +
" " +
cart.billing_address?.last_name,
address: {
city: cart.billing_address?.city ?? undefined,
country: cart.billing_address?.country_code ?? undefined,
line1: cart.billing_address?.address_1 ?? undefined,
line2: cart.billing_address?.address_2 ?? undefined,
postal_code: cart.billing_address?.postal_code ?? undefined,
state: cart.billing_address?.province ?? undefined,
},
email: cart.email,
phone: cart.billing_address?.phone ?? undefined,
},
}
await stripe
.confirmPayment({
clientSecret,
confirmParams,
redirect: "if_required",
})
.then(({ error, paymentIntent }) => {
console.log({ error, paymentIntent })
const validateIntent = async (paymentIntent: any) => {
const link =
paymentIntent.next_action?.oxxo_display_details
?.hosted_voucher_url
if (link) {
setSubmitting(false)
setMessage(
"Se ha generado un cupón de pago de OXXO. Por favor, revisa la nueva pestaña abierta."
)
await onPaymentCompleted() // Here I call the function because I have custom logic for creating a pending order
}
}
if (error) {
const pi = error.payment_intent
if (
(pi && pi.status === "requires_capture") ||
(pi && pi.status === "succeeded")
) {
onPaymentCompleted()
}
if (pi && pi.status === "requires_action") {
validateIntent(pi)
return
}
setErrorMessage(error.message || null)
setSubmitting(false)
return
}
if (
(paymentIntent && paymentIntent.status === "requires_capture") ||
(paymentIntent && paymentIntent.status === "succeeded")
) {
return onPaymentCompleted()
}
if (paymentIntent && paymentIntent.status === "requires_action") {
validateIntent(paymentIntent) // This is the action that you normally get
}
})
}
}
// Configuration on the server (medusa-config.ts)
modules: [
{
resolve: "@medusajs/medusa/payment",
options: {
providers: [
{
resolve: "@medusa/payment-stripe",
id: "stripe",
options: {
apiKey: process.env.STRIPE_API_KEY,
webhookSecret: process.env.STRIPE_WEBHOOK_SECRET,
capture: true,
oxxoExpiresDays: 7, // default to 3
},
},
],
},
},
],
// And not necessary buy you can extend even more creating a pending-orders module (for showing the vouchers created that costumer need to pay in the frontend, because if not the order only creates after the user have payed the voucher, for testing is 3 minutes), this is an example model:
import { model } from "@medusajs/framework/utils";
export const PendingOrder = model.define("pending_order", {
id: model.id().primaryKey(),
cart_id: model.text().unique(),
user_id: model.text(),
total: model.number(),
payment_type: model.text(),
voucher_url: model.text().nullable(),
payment_session_id: model.text(), // this are the ones that works to identify the payment
payment_collection_id: model.text(), // this are the ones that works to identify the payment
});
export default PendingOrder;
```
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [x] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [x ] I have linked the related issue(s) if applicable
---
## Additional Context
#13804
---
> [!NOTE]
> Adds OXXO payment support to the Stripe provider with configurable expiration days and updates intent option handling and typings.
>
> - **Payment Providers**:
> - **New `OxxoProviderService`** (`services/stripe-oxxo.ts`): configures `payment_intent` for OXXO with `expires_after_days` (defaults to `3`, configurable via `options.oxxoExpiresDays`).
> - Registered in `src/index.ts` and exported from `services/index.ts`.
> - **Types**:
> - `StripeOptions` adds `oxxoExpiresDays`.
> - `PaymentIntentOptions` adds `payment_method_options.oxxo.expires_after_days`.
> - `PaymentProviderKeys` adds `OXXO`.
> - **Core**:
> - `core/stripe-base.ts`: `normalizePaymentIntentParameters` now falls back to `this.paymentIntentOptions.payment_method_options` when not provided in `extra`.
> - **Changeset**:
> - Patch release for `@medusajs/payment-stripe`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4d7fe0658b91e6948f011a73d77a6281c85cdd26. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Co-authored-by: William Bouchard <46496014+willbouch@users.noreply.github.com>
## Summary
Updated context passed for each variant when calculating prices so that `region` and `customer` coming from `setPricingContext` are not overriden if provided.
*Please provide answer here*
Otherwise you can't provide your own `region` and `customer` objects with additional information and you are left with the ones we pass as part of the cart object to the workflows that execute the hook.
*Please provide answer here*
Changed the order in which we define the default `region` and `cart` fields, taking their value from the cart, to before the destructured `setPricingContextResult`.
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [x] I have linked the related issue(s) if applicable
---
## Additional Context
fixes#13990
closes SUP-2647
---
> [!NOTE]
> Adjust pricing context merge order so `setPricingContext`-provided `customer` and `region` are not overridden when calculating variant prices.
>
> - **Core Flows (pricing)**:
> - In `packages/core/core-flows/src/cart/workflows/get-variants-and-items-with-prices.ts`, change merge order when building `baseContext` so `customer` and `region` from `setPricingContextResult` take precedence over cart-derived values when pricing variants.
> - **Changeset**:
> - Add patch changeset for `@medusajs/core-flows`.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 010da7340909016692bea183d022dd0585abdb5a. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
