Skip to content

Releases: medusajs/medusa

v2.10.3: View configurations and Shipping Options context hook

18 Sep 16:51
@olivermrbl olivermrbl
v2.10.3
a503bbe

Choose a tag to compare

View all tags
v2.10.3: View configurations and Shipping Options context hook Latest
Latest

Highlights

[Experimental] Customizable columns in Medusa Admin tables

In previous versions, tables that list Orders, Products, etc., had hard-coded columns that couldn’t be modified. However, columns have different relevance between businesses. The only way to get tables to show additional columns was to introduce admin extensions that duplicated the original table’s behavior. This was tedious and clunky.

In this release, we are rolling out experimental support for View Configurations, which allow you to change which columns are displayed in the Orders and Products tables. Click the columns dropdown to see the available columns and add the ones you want. The available columns are computed using Medusa’s module graph, meaning any custom data models linked to Orders or Products can also be included in your table config.

With the View Configurations feature, we also enable saved views so you can have the right view at hand for your workflow. Saved views hold both your column configurations and any filters you have applied.

To try View Configurations turn on the feature flag in your medusa-config.ts

module.exports = defineConfig({
  ...
  featureFlags: {
    view_configurations: true
  }
})

Shipping options context hook

This release introduces a hook to customize the context used to list shipping options, allowing you to leverage custom rules for shipping options more easily.

The hook can be used like so:

import { listShippingOptionsForCartWithPricingWorkflow } from "@medusajs/medusa/core-flows"
import { StepResponse } from "@medusajs/workflows-sdk"

listShippingOptionsForCartWithPricingWorkflow.hooks.setShippingOptionsContext(
  async ({ cart }, { container }) => {

    if (cart.customer_id) {
      return new StepResponse({
        customer_id: cart.customer_id,
      })
    }

    const query = container.resolve("query")

    const { data: carts } = await query.graph({
      entity: "cart",
      filters: {
        id: cart.id,
      },
      fields: ["customer_id"],
    })

    return new StepResponse({
      customer_id: carts[0].customer_id,
    })
  }
)

In the example above, we add customer_id to the context along with the fixed properties is_return and enabled_in_store. This means that if a shipping option rule includes a customer_id attribute, the shipping option will be included in the result set.

The hook has been introduced in the following workflows:

  • listShippingOptionsForCartWithPricingWorkflow
  • listShippingOptionsForCartWorkflow

Please make sure to register the hook in both, since they are used for shipping option validation across workflows.

Features

Bugs

Documentation

Chores

  • chore(docs): Updated UI Reference (automated) by @github-actions[bot] in #13491
  • chore(docs): Update version in documentation (automated) by @github-actions[bot] in #13490
  • chore(js-sdk): add ignore tag to views by @shahednasser in #13503
  • chore: update TSDocs of JS SDK store methods to clarify required auth by @shahednasser in #13507
  • chore(core-flows): use directory convention for locking steps by @shahednasser in #13501
  • chore: add a link to the storefront docs for cart item totals type by @shahednasser in #13514
  • test(): test dynamic max workers and improve CI by @adrien2p in #13516
  • chore(): Shard unit tests jobs by @adrien2p in #13525
  • fix(core-flows): Lock cart on shipping + taxes update by @olivermrbl in #13535
  • chore: add tsdocs for latest changes by @shahednasser in #13539
  • fix(): Prevent promotion filtering to exceed psql limits by @adrien2p in #13540

Other Changes

  • fix(js-sdk): skip null values in query qs.stringify by @leobenzol in #13460
  • feat(dashboard): update display of tracking/label URLs on order details by @docloulou in #11613
  • fix(dashboard): added missing currencies by @tehaulp in #13214
  • test(): Try to reproduce automatic promotion adjustments being applied twice by @adrien2p in #13533

Full Changelog: v2.10.2...v2.10.3

Contributors

srindom, docloulou, and 8 other contributors
Assets 2
Loading

v2.10.2

12 Sep 13:57
@olivermrbl olivermrbl
v2.10.2
ed0dafb

Choose a tag to compare

View all tags
v2.10.2

Highlights

Indexing of core entities

Medusa Index was built to improve the developer experience of filtering data across modules while improving performance, especially for large data sets.

With this release, all entities in the core Medusa modules are now ingestible into Medusa Index. This unlocks cross-module filtering for all core and custom entities. The ingestion happens automatically, provided a link is defined between the entities, as described in our documentation.

For example, filtering Products by Sales Channels used to require the following steps:

// 🔴 BEFORE

const query = container.resolve("query")

// Sales Channels to filter by
const salesChannels = ["sc_1234"]

// Query the Sales Channel <> Product link table for matching links
const { data: links } = await query.graph({
  entity: "product_sales_channel",
  fields: ["product_id"],
  filters: {
    sales_channel_id: salesChannels
  }
})

// Construct the products filter using the matched links
const productFilters = {
  id: links.map(link => link.product_id)
}

// Finally query the products with the filters
const { data: products } = await query.graph({
  entity: "product",
  fields: ["id"],
  filters: productFilters
})

With Index, the same example from above can be done with a single query:

// 🟢 NOW

const query = container.resolve("query")

// Sales Channels to filter by
const salesChannels = ["sc_1234"]

// Query the products with the sales channel filter
const { data: products } = await query.index({
  entity: "product",
  fields: ["id"],
  filters: { sales_channels: { id: salesChannels } },
})

Note that in the second code snippet, we use query.index instead of query.graph to query Medusa Index.

For setup and usage details of Medusa Index, see our documentation.

Locking all cart operations

All cart workflows in Medusa's core are now locking the cart during execution to eliminate the risk of concurrent changes.

We would recommend that you introduce the same locking mechanism to your own custom cart workflows.

Here's how you would do it:

export const myCustomAddToCartWorkflow = createWorkflow("my-custom-add-to-cart-workflow",
  (input) => {
    // Acquire a lock on the cart ID as the first step in the workflow
    acquireLockStep({
      key: input.cart_id,
      timeout: 2, // Attempt to acquire the lock for two seconds before timing out
      ttl: 10, // Lock is only held for a maximum of ten seconds
    })

   // Run all regular cart operations

    // Release the lock on the cart ID as the last step in the workflow
    releaseLockStep({
      key: cart.id,
    })

    return new WorkflowResponse({ ... })
  }
)

Features

  • feat(promotion): Allow buyget promotion to apply multiple times on cart by @riqwan in #13305
  • feat(admin): add view configuration client infrastructure by @srindom in #13186
  • Feat/datatable core enhancements by @srindom in #13193
  • feat(ui): add column visibility and drag-and-drop reordering support by @srindom in #13198
  • feat(admin): add configurable order views by @srindom in #13211
  • feat(dashboard,cart,types,utils): refine order details summary by @willbouch in #13313
  • chore(orchestration): add support for autoRetry, maxAwaitingRetries, retryStep by @adrien2p in #13391

Bugs

Documentation

Chores

  • chore(docs): Update version in documentation (automated) by @github-actions[bot] in #13340
  • chore(docs): Updat...
Read more

Contributors

appinteractive, riqwan, and 19 other contributors
Loading

v2.10.1: Fixes regression in performance for cart operations

28 Aug 21:02
@olivermrbl olivermrbl
v2.10.1
4ee9c67

Choose a tag to compare

View all tags
v2.10.1: Fixes regression in performance for cart operations

Highlights

We identified a performance regression affecting cart operations in the latest release. This issue resulted in slower response times for cart-related HTTP requests. The regression was caused by a change introduced to control concurrency in cart operations, which inadvertently impacted performance.

To address this issue, we have reverted the change, restoring cart operation performance to its previous state. To prevent similar issues in future releases, we are implementing regression tests as part of our release pipeline. These tests will help detect performance regressions early in the development process, ensuring a more stable and reliable experience.

We apologize for the inconvenience this may have caused for some applications.

Documentation

Chores

  • chore(docs): Update version in documentation (automated) by @github-actions[bot] in #13327
  • chore(docs): Generated DML JSON files (automated) by @github-actions[bot] in #13328
  • chore: add since tag to shipping option type events by @shahednasser in #13331
  • chore(core-flows): revert idempotent cart by @carlos-r-l-rodrigues in #13336

Full Changelog: v2.10.0...v2.10.1

Contributors

shahednasser and carlos-r-l-rodrigues
Loading

v2.10.0: Draft Orders, Free shipping promotion, and Shipping Option Types

28 Aug 15:47
@olivermrbl olivermrbl
v2.10.0
94effdc

Choose a tag to compare

View all tags
v2.10.0: Draft Orders, Free shipping promotion, and Shipping Option Types

Highlights

This release contains breaking changes, so please read the release notes carefully. The breaking changes are all the result of fixing behavior that has not worked as intended until now.

Idempotency in our Workflow Engine

Warning

Breaking change

The idempotent configuration on workflows no longer retains executions in the database after completion, unless a retention time is specified. Up until now, if the idempotent flag was set, workflow executions were retained indefinitely, which was never the intention. The intention was to make a workflow idempotent for the duration of its execution, and only longer if the retention time was explicitly configured.

As part of this change, we are enabling the idempotent flag on all cart workflows to prevent concurrent mutations on cart operations.

Return type of methods in MedusaService

Warning

Breaking change

The return types of update and create in MedusaService have been corrected to properly handle the different shapes of inputs.

The behavior is now as follows:

createT({ ... }): T
createT([{ ... }]): T[]

updateT({ id: "br_1234", name: "Hermes"  }): T
updateT([{ id: "br_1234", name: "Hermes" }, { id: "br_4321", name: "Loewe"  }]): T[]
updateT({ selector: { country_of_origin: "France" }, data: { language: "French" }}): T[]

Compensating emitEventsStep

Warning

Breaking change

Previously, if the emitEventStep queued an event and the workflow later failed, the compensating flow would emit that queued event instead of removing it. This caused unexpected behavior during rollback.

With this change, when a workflow is compensated, all queued events emitted in the workflow are cleared. This was the intended behavior from the get-go, but the bug was only discovered recently.

If you want to keep the previous behavior, you can create your own version of the emitEventsStep without a compensation step.

Manage Shipping Option Types in Admin

Warning

Breaking change

The admin dashboard now supports managing shipping option types, making it easier to categorize options such as Standard and Express.

Key updates:

  • Settings: New "Shipping Option Types" page (accessible from "Locations & Shipping")
  • Create and update types with label, description, and code
  • Shipping option creation flow: Choose a type from a dropdown
  • Shipping option update flow: Change a type from a dropdown

This brings shipping option management to the dashboard, aligning it with existing backend support.

The introduction of Shipping Option Types comes with a migration, cleaning up old dummy types from the database. Up until now, we've created dummy types for Shipping Options as part of their creation flow. These types were placeholders, which is why we are now replacing them.

The migration will do the following:

  • Delete all Shipping Option Types with code type-code from the database
  • Disassociate these types from Shipping Options
  • Create a new Shipping Option Type named "Default" with code default
  • Associate the default type with Shipping Options

This migration will only affect Shipping Options that reference the type-code type. If you have been using your own types, they will remain as is. On the contrary, if you have been relying on type-code, this is a breaking change.

Draft Orders

The new Draft Order plugin adds flexible order management directly in Medusa Admin. Store admins can create, edit, and finalize orders through a dedicated UI, while developers gain a new primitive for building custom workflows.

Key features:

  • Create and manage draft orders from Medusa Admin
  • Support for custom pricing, line items, and shipping methods
  • Streamlined handling of B2B and complex sales

The Draft Order plugin is installed by default from version >=2.10.0. It is usable for version >=2.4.0 but requires explicit installation and registration.

Read more in our documentation.

Free shipping Promotions

This release introduces support for free shipping promotions available directly from the admin dashboard. You can apply free shipping to specific Shipping Option Types, e.g., "Standard", but not "Express".

Custom Logger Support

You can now replace the default logger with your own implementation by providing a class that follows the Logger interface.

Example:

// medusa-config.ts
import { MyCustomLogger } from "./custom-logger"

export default defineConfig({
  // ...
  logger: MyCustomLogger,
})

The logger should implement the Logger interface.

Shipping Option Tax Rates

You can now create tax rates specifically for shipping options within tax regions, similar to product-specific tax rates.

Metadata for Product Tags

The product tag domain now supports metadata, with a UI for creating and managing metadata values.

Features

Bugs

  • fix(utils): fix promotion case of each allocation not applying its total amount by @riqwan in #13199
  • fix(utils): auto generated update method return by @carlos-r-l-rodrigues in #13225
  • fix(dashboard): table inclusive date filter by @fPolic in #13053
  • fix(dashboard): create product selected inventory item display by @fPolic in #13111
  • fix(core-flows, dashboard, types): improve allocation flows on Admin by @fPolic in #12572
  • fix(dashboard): zero in float currency inputs by @fPolic in #13267
  • fix(dashboard): show fulfilment option on SO edit by @fPolic in #13269
  • fix(fulfillment): Geozone constraints builder by @olivermrbl in #13282
  • fix(): Cart operation should calculate item prices accounting for quantity by @adrien2p in #13251
  • fix(fulfillment): don't cascade shipping option delete to shipping option type by @fPolic in #13280
  • fix: Add created_at to workflow execution filtering typings by @sradevski in #13295
  • fix(dashboard): handle large resource count in tax rule override edit form by @fPolic in #13297
  • fix(medusa): fetching a product without a category with categories filed passed by @fPolic in #13020
  • fix(core-flows): pass backorder flag when recreating reservations after fulfilment cancelation by @fPolic in #13076
  • fix(core-flows): list order shipping options param type by @fPolic in #13316

Documentation

Read more

Contributors

larsdecker, almousa1990, and 15 other contributors
Loading

v2.9.0

14 Aug 12:47
@olivermrbl olivermrbl
v2.9.0
61a25dd

Choose a tag to compare

View all tags
v2.9.0

Highlights

Throw error on invalid promotions

Warning

Breaking change

This release updates the promotion application logic to throw when applying an invalid promotion code. This change improves the experience for developers building storefronts by allowing them to handle invalid discount codes directly from the API response, rather than checking cart promotions after the API request.

The backend will respond with a 400 and a message like so:

The promotion code HELLOWORLD is invalid

Add support for logical operators on Index

This release introduces support for logical operators on Index queries, such as:

const { data: products } = await query.index({
  entity: "product",
  filters: {
    $and: [
      { status: "published" },
      {
        $or: [
          { brand: { name: { $ilike: "%adidas%" } } }
        ]
      }
    ]
  }
})

In addition to this, this release also fixes a regression related to indexing custom module entities.

Resolve issue with promotion calculations in a tax-inclusive context

This release resolves an issue with the calculation of adjustments in a tax-inclusive calculation context.

When calculating the applicableTotal (the maximum amount a promotion can apply to an item), it was incorrectly based on the line item’s subtotal (excluding tax), while the promotion value was based on the total (including tax), causing incorrect adjustment calculations.

Bugs

Documentation

Chores

Other Changes

  • fix(dashboard): correct overflow in a few settings edit forms by @SteelRazor47 in #11982
  • fix: createCustomerGroupsStep rollback, delete created customer groups… by @jbrigbyjs in #13056
  • This fixes the discount_ calculation logic and promotion tax inclusiveness calculation by @scherddel in #12960
  • feat: added pacific franc currency by @tehaulp in #13086
  • fix(types,utils,promotion): Move from total to original_total to resolve edge case for adjustments calculation by @scherddel in #13106
  • fix(utils):Fix on precision for high quantities for items when promotion is applied by @scherddel in #13131
  • Made in operator work as In insted of equal logic by @mikkel-lindstrom in #13078

New Contributors

...

Read more

Contributors

aldo-roman, sradevski, and 13 other contributors
Loading

v2.8.8: Improved error logging and overall robustness of core operations

24 Jul 08:08
@olivermrbl olivermrbl
v2.8.8
394226b

Choose a tag to compare

View all tags
v2.8.8: Improved error logging and overall robustness of core operations

Highlights

Carry over cart promotions to order

The cart-completion workflow has been updated to transfer promotions from carts to orders upon completion. This means you can now access promotions on the order like so:

const { data } = await query.graph({
  entity: "order",
  fields: ["id", "promotions.*"]
})

const order = data[0]

console.log(order.promotions)

// [{
//   "id": "promo_1234",
//   "code": "10OFF",
//   "is_automatic": false,
//   "is_tax_inclusive": false,
//   "type": "standard",
//   "status": "active",
//   "campaign_id": null,
//   "campaign": null,
// }]

Previously, promotions had to be accessed via the line item adjustments on the order.

Align accepted values in product import template

The CSV product import functionality has been updated to correctly handle unexpected columns. These columns are now ignored during import, ensuring a smoother process for creating and updating products.

Improved error logging

Client-side 4xx responses (such as 404s) are no longer logged as errors. These responses typically indicate expected conditions. Only 5xx responses, which indicate server-side issues, are now logged as errors. This reduces unnecessary noise in logs, making it easier to focus on actual server problems.

Expanded order methods in the JS SDK

Added archive and complete methods to the admin.order module of the JS SDK. These methods provide support for the POST /admin/orders/{id}/archive and POST /admin/orders/{id}/complete endpoints, giving developers full access to the order lifecycle directly from the SDK.

The methods are used like so:

await sdk.admin.order.archive("order_123");
await sdk.admin.order.complete("order_123");

Bugs

  • fix(link-modules,core-flows): Carry over cart promotions to order promotions by @riqwan in #12920
  • fix(core-flows): updating tax lines when draft order shipping is removed by @fPolic in #12919
  • fix(types): add attachments to CreateNotificationDTO type by @shahednasser in #12936
  • fix(dashboard): combobox multiitem clear by @fPolic in #12939
  • fix(core-flows): useQueryGraph util return type by @adrien2p in #12962
  • chore(workflow-engine-*): Align event subscribers management by @adrien2p in #12976
  • fix(orchestration): Prevent workf. cancellation to execute while rescheduling by @adrien2p in #12903
  • fix: accepted values in import with template by @juanzgc in #12969
  • fix(core-flows): properly delete variant inventory item by @fPolic in #12958
  • chore(link-modules): keep promotion alias by @riqwan in #12928
  • fix(wfe): should notify when finished + add state info by @adrien2p in #12982
  • fix(wfe): add missing state in inmemory notify on run finished by @adrien2p in #12987
  • fix(dashboard): allocation UI for orders with more than 20 reservation items by @fPolic in #12989
  • fix(pricing): fix pricing query when max_quantity is null by @riqwan in #12981
  • fix: fix script migrations order by @peterlgh7 in #13007
  • fix(workflows-sdk): fix step name config used before default by @carlos-r-l-rodrigues in #12926
  • fix(modules-sdk): Entity types by @olivermrbl in #13002
  • fix(dashboard, product): product attributes update with a relation update by @fPolic in #13019

Documentation

Chores

Other Changes

New Contributors

Read more

Contributors

mathieuh, anteprimorac, and 14 other contributors
Loading

v2.8.7: Improved `create-medusa-app` and corrected tax calculations

08 Jul 17:56
@olivermrbl olivermrbl
v2.8.7
1ee146e

Choose a tag to compare

View all tags
v2.8.7: Improved `create-medusa-app` and corrected tax calculations

Highlights

New --version flag for create-medusa-app

This release introduces a new flag, --version to the create-medusa-app command, allowing you to create Medusa projects with a specific version installed.

npx create-medusa-app ---version 2.8.5

Correct tax calculations for order item adjustments

This release introduces the is_tax_inclusive flag on order line item adjustments to ensure tax calculations are correct for tax-inclusive promotions.

Features

  • feat(create-medusa-app): Allow to create project with specific medusa version by @adrien2p in #12882

Bugs

Documentation

Other Changes

  • fix(admin): prevent excessive polling in notifications by @jessy2027 in #12868

New Contributors

Full Changelog: v2.8.6...v2.8.7

Contributors

fPolic, adrien2p, and 3 other contributors
Loading

v2.8.6: Strengthened workflow engine and improved account holder management

30 Jun 14:23
@olivermrbl olivermrbl
v2.8.6
ac76e19

Choose a tag to compare

View all tags
v2.8.6: Strengthened workflow engine and improved account holder management

Highlights

Strengthen the workflow engine

This release improves the workflow engine's data flow. When resuming workflows, we now compile workflow data (i.e. input and outputs of previous steps) from Redis and Postgres to ensure the most recent workflow execution and associated data are used.

Improve payment account holder flows

This release improves how payment account holders are managed when creating payment sessions in the createPaymentSessionWorkflow. In this workflow, we create a new payment account holder for the customer on the cart if it doesn't already exist. When the workflow fails in a later step, the compensation flow is triggered, and we now ensure we are only deleting the account holder if it was created as part of the invoke, i.e. it didn't exist before running the workflow.

Bugs

  • fix: do not apply prefix when getting file contents as buffer or stream by @thetutlage in #12831
  • fix(core-flows,workflows-sdk): compensate account holders only when its created by @riqwan in #12825
  • fix(): test utils events + workflow storage by @adrien2p in #12834
  • fix: fix onScroll in Select.Content by @peterlgh7 in #12855

Documentation

Chores

Other Changes

New Contributors

Full Changelog: v2.8.5...v2.8.6

Contributors

redeyecz, thetutlage, and 5 other contributors
Loading

v2.8.5: Tax-inclusive Promotions, Improved Product Imports, and Faster Application Startup

25 Jun 09:58
@olivermrbl olivermrbl
v2.8.5
e0b5bb0

Choose a tag to compare

View all tags
v2.8.5: Tax-inclusive Promotions, Improved Product Imports, and Faster Application Startup

Highlights

Improved Product Imports

This release overhauls the bulk import process to make it more performant and include strict validations to catch formatting issues or typos during the pre-processing phase.

Import phases

A CSV file with products to import goes through the following two phases.

  • Pre-processing: In the pre-processing phase, we validate the contents of the entire file, check for typos, unknown columns, invalid data types, or missing values, and report errors as soon as you upload the file.
  • Importing: Products are imported in the background (as it could be time-consuming with large product catalogs). Since the validations have already been performed during the pre-processing phase, the chances of failure during the import phase are rare. However, certain database constraints around duplicate data might result in a failure.

Changes to import template

Earlier, the import template (downloaded from the admin dashboard) was out of sync with our documentation and supported many columns that were part of Medusa V1.

However, now the import template strictly allows the columns mentioned in the documentation, and an error will be raised if an unknown column is specified in the CSV file.

Performance improvements

The following changes have been made to the internals to improve the import performance and memory consumption.

  • Use S3 direct uploads instead of self-importing and storing huge CSV files on a Medusa server. For this, you must configure the S3 file provider in production.
  • Read the CSV contents as a stream of chunks and process/validate 1000 rows at a time. As a result, we never read or process the entire CSV file in memory. From our tests, this led to a memory drop from 4GB to 500MB when processing a file with 62000 rows.

Tax-inclusive Promotions

This release introduces an option to specify if fixed promotions take effect before or after taxes. Up until now, fixed promotions would always be applied before taxes, which could lead to unexpected total calculations in scenarios where pricing was otherwise tax-inclusive.

For example, consider a fixed promotion with a value of $10 applied to a tax-inclusive cart of $100 in a tax region with a 25% tax rate.

Before promotion is applied:

  • Cart total (tax-inclusive) -> $100 ($80 ex. 25% VAT)

After promotion is applied:

  • Cart total (tax-inclusive) -> $87.5 ($70 ex. 25% VAT)

As you can see, the cart is reduced by $12.5 even though the promotion value was $10. The calculation we used to perform to find the promotion adjustment was:

const adjustmentTotal = (cartWithoutTax - promotion.value) * (1 + tax_rate)

In our example, this would be:

const adjustmentTotal = (80 - 10) * (1.25) = 87.5

In this release, we updated this calculation to ensure the correct adjustment total. It looks as follows:

const adjustmentTotal = (cartWithoutTax - (promotion.value / 1 + tax_rate)) * (1 + tax_rate)

In our example, this would be:

const adjustmentTotal = (80 - 8) * (1.25) = 90

The tax-inclusivity option on a promotion is part of the promotion creation flow in the admin dashboard.

Improved application startup time

This release reduces application startup time by around ~75%. For example, on Medusa Cloud, the startup time for a relatively simple Medusa application has gone from 20 seconds to around 4 seconds. This improvement comes from parallelizing the bootstrapping of modules. Modules are strictly independent from each other, so this should have no side effects.

Querying deleted records

This release fixes issues with querying for deleted database records.

Up until now, filtering data by providing any value to the deleted_at filter would be treated as if you wanted to fetch deleted records.

For example:

const { data } = await query.graph({
  entity: "product",
  filters: { deleted_at: { $eq: null } }
})

In this query request, we are asking for all non-deleted records; however, we mistakenly assumed that any deleted_at filter would always be filtering for deleted records, so in this case, the result set would contain deleted records.

In this release, we remove the autodetection mechanism in favor of an explicit flag withDeleted.

To query deleted records, you now need to pass the flag to the request:

const { data } = await query.graph({
  entity: "product",
  filters: { deleted_at: { "<some timestamp>" } }
  withDeleted: true
})

Features

  • feat: wire up direct uploads with local file provider by @thetutlage in #12643
  • feat(promotion, dashboard, core-flows, cart, types, utils, medusa): tax inclusive promotions by @fPolic in #12412
  • feat(dashboard,types): add credit lines + loyalty changes by @riqwan in #11885
  • feat: Improve startup time by parallelizing module and link loading by @sradevski in #12731
  • feat: Normalize payment method data and options when passed to Stripe by @sradevski in #12757
  • fix(dashboard, types): loyalty UI changes by @fPolic in #12764
  • feat(): Add support for jwt asymetric keys by @adrien2p in #12813
  • feat: add cookie options by @riqwan in #12720

Bugs

  • fix(workflow-sdk): Async/nested runAsStep propagation by @adrien2p in #12675
  • fix: update product import template by @thetutlage in #12697
  • fix(create-medusa-app): remove "Created admin user" message by @shahednasser in #12707
  • fix(promotion, types): non discountable items check by @fPolic in #12644
  • fix: remote query types by @thetutlage in #12712
  • fix(core-flows): cart complete order address creation by @fPolic in #12493
  • fix(utils): medusa internal service returned data should match typings by @adrien2p in #12715
  • fix(utils): Typecasting non-text fields in FTS by @olivermrbl in #12729
  • fix: Disable ensure database checks when establishing DB connection by @sradevski in #12734
  • fix(create-medusa-app): ensure the same package manager is used consistently by @shahednasser in #12714
  • fix(payment): add account holder methods to the manual provider by @fPolic in #12751
  • fix(core, medusa-test-utils): Fix medusa test runner plugin modules loading by @adrien2p in #12753
  • fix: Add missing partially funded event handler for Stripe by @sradevski in #12763
  • fix: initiate request container before other express middleware by @thetutlage in #12761
  • fix(dashboard): fix subtitle for tax inclusive fields in promotions by @shahednasser in #12776
  • fix(workflow-engine-redis): Ensure PK is set without errors by @olivermrbl in #12775
  • fix: add operators to RemoteQueryFilters by @peterlgh7 in #12735
  • fix: Return and set the correct status when a session is created with… by @sradevski in #12769
  • fix: Allow setting the status of a payment session when updating by @sradevski in #12809
  • fix(workflow-engine-*): Cleanup expired executions and reduce redis storage usage by @adrien2p in #12795
  • fix(medusa): Query Config update Order By filter by @juanzgc in #12781
  • fix(payment): round currency precision by @carlos-r-l-rodrigues in #12803
  • fix(dashboard): fix currency input locale formatting by @fPolic in #12812
  • fix(utils): build query withDeleted remove auto detection by @adrien2p in #12788
  • fix: Add missing migration for payment statuses by @sradevski in #12821

Documentation

Read more

Contributors

anteprimorac, thetutlage, and 10 other contributors
Loading

v2.8.4: Strengthening of cart-completion flows

05 Jun 18:43
@olivermrbl olivermrbl
v2.8.4
cab00ff

Choose a tag to compare

View all tags
v2.8.4: Strengthening of cart-completion flows

Highlights

Eliminate race condition in cart-completion flow

This release strengthens the cart-completion flow by eliminating a potential race condition that, in rare cases, could result in an incorrectly refunded payment.

The race condition occurs when cart completion is triggered from two sources: 1) the regular HTTP request to POST /store/carts/:id/complete, and 2) a webhook event from the payment provider signaling successful payment authorization.

To reduce the risk of a conflict, we have, up until now, delayed webhook processing by 5 seconds. However, this mitigation proved insufficient in some cases.

Now, whenever the completeCartWorkflow is executed whether via the API route or the webhook handler, we now hold a lock on the cart ID for the duration of the workflow. This lock ensures that multiple completion attempts for the same cart are processed sequentially. Once a cart is successfully completed (typically on the first attempt), subsequent attempts will detect the completed cart and exit early, returning the associated order.

Features

Bugs

Documentation

Chores

  • chore(modules-sdk): Log full error when a loader fail to run by @adrien2p in #12584
  • chore(core-flows): ignore hooks in complete cart workflow by @shahednasser in #12600

Other Changes

New Contributors

Full Changelog: v2.8.3...v2.8.4

Contributors

thetutlage, leosin, and 8 other contributors
Loading