**What**
- ProductService.create calls ProductService.retrieve before returning. This fix ensures that the manager created in the atomicPhase is used when ProductService.retrieve is called.
**Why**
- Without the explicit use of the same manager in the retrieve call, race conditions easily occur if you have concurrent ProductService.create calls. The code below can reproduce the scenario:
```javascript
const productData = [
{
barcode: `1234233423-${Math.random() * 100}`,
external_id: `1234233423-${Math.random() * 100}`,
description: "super cool product",
discountable: true,
hs_code: "1234213",
origin_country: "DK",
title: `Super cool product ${Math.random() * 100}`,
type: { value: "Eyewear" },
sales_channels: [{ id: sc.id }],
},
{
barcode: `1234233423-${Math.random() * 100}`,
external_id: `random-external-id-${Math.random() * 100}`,
description: "super cool product",
discountable: true,
hs_code: "1234213",
origin_country: "DK",
title: `Super cool product ${Math.random() * 100}`,
type: { value: "Eyewear" },
sales_channels: [{ id: sc.id }],
},
];
const result = await Promise.all(
productData.map(async (product) => productService.create(product))
);
```
**Explaination**
What happens is the following:
- Request 1 calls `ProductService.create`. This in turn calls `atomicPhase` which sets the `ProductService.transactionManager_ = txForReqOne`
- Request 1 creates the product in the DB with `txForReqOne`.
- Request 2 calls `ProductService.create`. This in turn calls `atomicPhase` which sets the `ProductService.transactionManager_ = txForReqTwo`
- Request 1 reaches the end of `ProductService.create` where `this.retrieve` is called. Because the ProductService is a singleton the retrieve call will attempt to use `txForReqTwo` to fetch the product.
- **Error**: since `txForReqTwo` can't read the data of `txForReqOne`, the product is not found.
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- Migrate Stripe plugin to use API Routes + Subscribers
- Change the behaviour of Stripe webhook
Instead of processing webhook events immediately, we fire an event to perform the work in the background. The primary reason for changing the webhook is that the previous implementation led to occasional conflicts due to a race condition between the client's and the webhook's request to complete a cart. Now, we emit an event with a configurable delay (defaults to 2s) to prevent this from happening
This approach was preferred over adding a timeout directly to the webhook execution, as it is generally best practice to respond to a webhook event immediately after receiving it.
* init
* remove date string validator;
* add transformOptionalDate transformer to api
* move type conversion to the datalayer
* fix final module integration test
* update arrow-function
* make string optional
* move work to utils
* make check for value exists
* move util back to pricng
* change utils
* refactor get-iso-string
* fix build
* flip transform condition
* add null check for isDate
* feat(pricing): Separate Pricing Module internal types from `@medusajs/types` (#5777)
* create types for pricing repositories
* create RepositoryTypes input
* add service types
* use models for repository types
* fix build
* update types to match interface types
* add aliases
* types instead of moduletypes
* move repository to types for pricing module
* add changeset
* fix merge error
* fix conflict
* fix build
* re-add validation of dates in updatePriceLists_
**What**
One problem with local development can be the dependencies management. To mitigate that, transform checks from an instance of to value check as well as harmonize utils function to be part of the class as a static method instead of separate utilities. By using this approach we are not dependent of the origin of the class and therefore it should ease the user experience.
**NOTE**
As a next step to discuss, we should probably move the interfaces from the interfaces/medusa package to the utils package. Then we can deprecate the interfaces package and remove it at a later time
**What**
- Add price-rules for prices in price-lists
- make rules object optional when creating prices
**Why**
- more price granularity
Co-authored-by: Philip Korsholm <88927411+pKorsholm@users.noreply.github.com>
* adjusted configurations
* enhancements to tool and configurations
* change reference in docs
* fixed issue in workflows reference
* added project name
* more optimizations
* fix context error
* added a types reference
* resolved missing types
* fix reference reflection types not having children
* add an expand url parameter
* added new option to the README
* added details about new option
**What**
- ensure that an error is raised properly if the requested product doesn't exist and a publishable-key header is set
**Why**
- previously endpoints would hang if the product didn't exist and requests would time out
closes#5724
Riqwan Thamir
Sebastian RindomandOli Juhl
Shahed Nasser
olivermrbl
Adrien de Peretti
Sajarin M
Mohamed Abusaid
Frane Polić
cyf0e
Philip Korsholm
Katarzyna StokłosaandRiqwan Thamir
Zarar Siddiqi
josetr
mortenengelandOli Juhl
pepijn-vanvlaanderen
