* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* Create lucky-poets-scream.md
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* chore(): Cleanup and organize deps
* dedupe snapshot this build
* split into 4 shard
* re configure packages integration tests
* re configure packages integration tests
* re configure packages integration tests
* re configure packages integration tests
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* update scripts
* reduce shard for packages
* feat(index): Add support to trigger sync manually
* feat(index): Add API route to interact with
* feat(index): Add API route to interact with
* feat(index): Add API route to interact with
* test(): Add http integration tests
* Create weak-elephants-reply.md
* feat(): version order credit lines
* undo last change
* adjust where
* remove date on ui
* Create five-donuts-obey.md
* add test
* nit comment
* woops
## Summary
**What** — What changes are introduced in this PR?
This PR fixes a bug where async workflow steps with retry intervals would get stuck after the first retry attempt due to Bull queue jobId collisions preventing retry jobs from executing.
**Why** — Why are these changes relevant or necessary?
Workflows using async steps with retry configurations (e.g., `retryInterval: 1`, `maxRetries: 5`) would fail once, schedule a retry, but the retry job would never execute, causing workflows to hang indefinitely.
**How** — How have these changes been implemented?
**Root Cause:** Bull queue was rejecting retry jobs because they had identical jobIds to the async execution jobs that already completed. Both used the format: `retry:workflow:transaction:step_id:attempts`.
**Solution:** Modified `getJobId()` in `workflow-orchestrator-storage.ts` to append a `:retry` suffix when `interval > 0`, creating unique jobIds:
- Async execution (interval=0): `retry:...:step_id:1`
- Retry scheduling (interval>0): `retry:...:step_id:1:retry`
Updated methods: `getJobId()`, `scheduleRetry()`, `removeJob()`, and `clearRetry()` to pass and handle the interval parameter.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Added integration test `retry-interval.spec.ts` that verifies:
1. Step with `retryInterval: 1` and `maxRetries: 3` executes 3 times
2. Retry intervals are approximately 1 second between attempts
3. Workflow completes successfully after retries
4. Uses proper async workflow completion pattern with `subscribe()` and `onFinish` event
---
## Examples
```ts
// Example workflow step that would previously get stuck
export const testRetryStep = createStep(
{
name: "test-retry-step",
async: true,
retryInterval: 1, // 1 second retry interval
maxRetries: 3,
},
async (input: any) => {
// Simulate failure on first 2 attempts
if (attempts < 3) {
throw new Error("Temporary failure - will retry")
}
return { success: true }
}
)
// Before fix: Step would fail once, schedule retry, but retry job never fired (jobId collision)
// After fix: Step properly retries up to 3 times with 1-second intervals
```
---
## 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
-
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
Fixes#13735
### What
This Pull Request introduces new database migrations to remove multiple redundant indexes across several core modules, including product, cart, order, customer, and inventory.
### Why
As detailed in issue #13735, a fresh Medusa installation produces numerous "Duplicate Index" warnings. These legacy indexes add unnecessary write overhead and provide no performance benefit. This PR cleans up the schema to resolve these warnings and improve database health.
### How
I have added one new, reversible migration file for each of the five affected modules:
- `@medusajs/product`
- `@medusajs/cart`
- `@medusajs/order`
- `@medusajs/customer`
- `@medusajs/inventory`
Each migration's `up()` method safely drops the older, redundant index, and its `down()` method re-creates it, ensuring the change is fully reversible and non-destructive.
### Testing
I have tested these migrations by following the local development workflow outlined in the `CONTRIBUTING.md` guide.
1. **Setup:**
* Cloned my forked Medusa repository locally .
* Created a separate, fresh test project using `npx create-medusa-app@latest my-medusa-store`.
* The test project's PostgreSQL database, which already contained the schema with the duplicate indexes.
2. **Linking Local Source Code:**
* In the test project's `package.json`, I modified all `@medusajs/*` dependencies and resolutions to point to the local packages in my forked repository (e.g., `"@medusajs/product": "file:../medusa/packages/modules/product"`).
* From the test project's directory, I ran `yarn install` to link the local, modified Medusa source code into its `node_modules`.
3. **Build & Migration:**
* Inside my forked Medusa repository, I ran `yarn build` to compile the new TypeScript migration files.
* From the root of the **test project**, I then executed the migration command: `npx medusa migration run`.
4. **Verification:**
* The command successfully identified and ran only the new migration files I had created.
* I also confirmed via direct SQL queries that the old, redundant indexes were correctly dropped from all affected tables (`product_collection`, `customer_group`, etc.).
## Summary
**What** — What changes are introduced in this PR?
Add a method in the Tax Module's servie to retrieve a provider by its ID.
**Why** — Why are these changes relevant or necessary?
The Tax Module Provider could be used for use cases other than calculating tax lines. For example, Avalara supports importing products to manage product-specific taxes. However, it's not possible right now to listen to the `product.created` event and create the product in Avalara with its provider. Instead, you'll have to create a separate module that also connects to Avalara and resolve it in the subsriber.
This also matches the pattern in the Analytics Module, which allows retrieving the underlying provider.
**How** — How have these changes been implemented?
Add a `getProvider` method to the Tax Module's service and its interface.
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Added integration test for the method.
---
## 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
const avalaraProvider = taxModuleService.getProvider("tp_avalara_avalara")
```
---
## 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
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
### What
Add a new `once` allocation strategy to promotions that limits application to a maximum number of items across the entire cart, rather than per line item.
### Why
Merchants want to create promotions that apply to a limited number of items across the entire cart. For example:
- "Get $10 off, applied to one item only"
- "20% off up to 2 items in your cart"
Current allocation strategies:
- `each`: Applies to each line item independently (respects `max_quantity` per item)
- `across`: Distributes proportionally across all items
Neither supports limiting total applications across the entire cart.
### How
Add `once` to the `ApplicationMethodAllocation` enum.
Behavior:
- Applies promotion to maximum `max_quantity` items across entire cart
- Always prioritizes lowest-priced eligible items first
- Distributes sequentially across items until quota exhausted
- Requires `max_quantity` field to be set
### Example Usage
**Scenario 1: Fixed discount**
```javascript
{
type: "fixed",
allocation: "once",
value: 10, // $10 off
max_quantity: 2 // Apply to 2 items max across cart
}
Cart:
- Item A: 3 units @ $100/unit
- Item B: 5 units @ $50/unit (lowest price)
Result: $20 discount on Item B (2 units × $10)
```
**Scenario 2: Distribution across items**
```javascript
{
type: "fixed",
allocation: "once",
value: 5,
max_quantity: 4
}
Cart:
- Item A: 2 units @ $50/unit
- Item B: 3 units @ $60/unit
Result:
- Item A: $10 discount (2 units × $5)
- Item B: $10 discount (2 units × $5, remaining quota)
```
**Scenario 3: Percentage discount - single item**
```javascript
{
type: "percentage",
allocation: "once",
value: 20, // 20% off
max_quantity: 3 // Apply to 3 items max
}
Cart:
- Item A: 5 units @ $100/unit
- Item B: 4 units @ $50/unit (lowest price)
Result: $30 discount on Item B (3 units × $50 × 20% = $30)
```
**Scenario 4: Percentage discount - distributed across items**
```javascript
{
type: "percentage",
allocation: "once",
value: 15, // 15% off
max_quantity: 5
}
Cart:
- Item A: 2 units @ $40/unit (lowest price)
- Item B: 4 units @ $80/unit
Result:
- Item A: $12 discount (2 units × $40 × 15% = $12)
- Item B: $36 discount (3 units × $80 × 15% = $36, remaining quota)
Total: $48 discount
```
**Scenario 5: Percentage with max_quantity = 1**
```javascript
{
type: "percentage",
allocation: "once",
value: 25, // 25% off
max_quantity: 1 // Only one item
}
Cart:
- Item A: 3 units @ $60/unit
- Item B: 2 units @ $30/unit (lowest price)
Result: $7.50 discount on Item B (1 unit × $30 × 25%)
```
**What**
- implement promotion usage limits per customer/email
- fix registering spend usage over the limit
- fix type errors in promotion module tests
**How**
- introduce a new type of campaign budget that can be defined by an attribute such as customer id or email
- add `CampaignBudgetUsage` entity to keep track of the number of uses per attribute value
- update `registerUsage` and `computeActions` in the promotion module to work with the new type
- update `core-flows` to pass context needed for usage calculation to the promotion module
**Breaking**
- registering promotion usage now throws (and cart complete fails) if the budget limit is exceeded or if the cart completion would result in a breached limit
---
CLOSES CORE-1172
CLOSES CORE-1173
CLOSES CORE-1174
CLOSES CORE-1175
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
**What**
After lot of investigation, we finally found one of our performance regerssion point (see [here](https://github.com/mikro-orm/mikro-orm/issues/6905)), this pr downgrade mikro orm and move the strategy back to select in where needed
Fixes#13625
---
> [!NOTE]
> Ensure `reserved_quantity` is adjusted when deleting reservation items via `deleteReservationItems`, with new integration tests covering deletion and inventory updates.
>
> - **Inventory Module Service (`packages/modules/inventory/src/services/inventory-module.ts`)**:
> - Add `deleteReservationItems` API (and transactional `_` variant) that hard-deletes reservations, then updates related inventory levels via `adjustInventoryLevelsForReservationsDeletion`.
> - Wire through event emission/manager decorators consistent with existing patterns.
> - **Integration Tests (`packages/modules/inventory/integration-tests/__tests__/inventory-module-service.spec.ts`)**:
> - Add tests for `deleteReservationItems` to verify deletion by id and `reserved_quantity` adjustments on inventory levels.
> - Minor import update to include `ReservationItemDTO`.
> - **Changeset**:
> - Patch release note for `@medusajs/inventory` documenting the fix.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ac6641a9ec9543115504407f708f81bd427c3444. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
RESOLVES CORE-1153
**What**
- This pr mainly lay the foundation the caching layer. It comes with a modules (built in memory cache) and a redis provider.
- Apply caching to few touch point to test
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
**What**
The context reference is being mutated by the repository leading to an empty context. Also, the filter is built from the pricing context instead of pricing context -> context leading to always fetch all preferences all the time
PARTIALLY RESOLVES CORE-1156
**What**
Improve upsertWithReplace to batch as much as possible what can be batched. Performance of this method will be much greater specially for cases with maybe entities and batch (e.g we seen many cases where they bulk product with hundreds variants and options etc)
for example let take the following object:
- entity 1
- entity 2 []
- entity 3 []
- entity 2 []
- entity 3 []
here all entity 3 will be batched and all entity 2 will be batched
I ve also added a pretty detail test that check all the stage and what is batched or not with many comments so that it is less harder to consume and remember in the future
Also includes:
- mikro orm upgade (issues found and fixes)
- order module hooks fixes
**NOTE**
It was easier for now to do this instead of rewriting the different areas where it is being used, also, maybe it means that we will have closer performance to what we would expect to have natively
**NOTE 2**
Also fix the fact that integration tests of the core packages never ran 😂
