MSI enabled, but Magento_CatalogInventory observers still trigger (N+1 risk)

[MagePsycho]

MSI enabled, but Magento_CatalogInventory observers still trigger (N+1 risk). Can we rely solely on MSI observers?

Context We run with MSI enabled, yet Magento_CatalogInventory observers are still active:

<!-- From CatalogInventory -->
<event name="sales_quote_item_collection_products_after_load">
    <observer name="add_stock_items" instance="Magento\CatalogInventory\Observer\AddStockItemsObserver"/>
</event>
<event name="sales_quote_item_qty_set_after">
    <observer name="inventory" instance="Magento\CatalogInventory\Observer\QuantityValidatorObserver"/>
</event>

MSI also registers:

<event name="sales_quote_item_collection_products_after_load">
    <observer name="inventory_catalog_preload_cache" instance="Magento\InventoryCatalog\Observer\PreloadCache"/>
</event>

Problem

With MSI, AddStockItemsObserver appears redundant.

Magento\CatalogInventory\Observer\QuantityValidatorObserver can still incur N+1 lookups unless stock data is fully preloaded.

We’re seeing performance drag in cart/checkout flows even though MSI should be the source of truth.

Proposal

1. Disable add_stock_items (CatalogInventory) and rely on MSI’s inventory_catalog_preload_cache.
2. Optimize or replace Magento\CatalogInventory\Observer\QuantityValidatorObserver with an MSI-aware validator that:
   • Uses preloaded stock data,
   • Avoids per-item stock registry calls,
   • Falls back gracefully if preload misses.

Questions

1. Is it officially supported to disable AddStockItemsObserver when MSI is enabled?
2. Has the team addressed the slowness/N+1 in QuantityValidatorObserver for MSI setups?

Any recommended best practices or reference implementations for an MSI-native quantity validator?

Goal Eliminate redundant observers and ensure quantity validation is MSI-native and preload-aware, removing N+1 queries from cart/checkout.

[m2-assistant[bot]]

Hi @MagePsycho. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[m2-assistant[bot]]

Hi @engcom-Hotel. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• [ ] 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• [ ] 5. Add label Issue: Confirmed once verification is complete.
• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[engcom-Hotel]

Hello @MagePsycho,

Thanks for the report and collaboration!

We have tried to reproduce the issue via creating a custom module, which I am going to share below. But it seems the issue mentioned is not reproducible for us. We were trying if the MSI is enabled then, both the conflicting observer called or not.

But it seems in our case, this is not happening. Please refer to the below steps we have followed to reproduce the issue:

1. Install the Module

   bin/magento module:enable Magz_Issue40186
   bin/magento setup:upgrade
   bin/magento cache:flush
   

2. Analyze Current System

   bin/magento magz:issue40186:analyze-conflicts --detailed
   

3. Reproduce the Issue

   # Add products to cart (via storefront or API)
   # This will trigger the conflicting observers
   

4. Monitor Logs

   tail -f var/log/system.log | grep "Issue40186"
   

Issue40186.zip

For us when we monitor the logs, we are getting the output as below:

Entry 1: Initial Quantity Validation

{
  "product_id": "1",
  "product_sku": "product_dynamic_1", 
  "quote_item_id": null,
  "qty": 1.0,
  "execution_time_ms": 0.037,
  "queries_executed": 0,
  "validation_count": 1,
  "timestamp": "2025-09-11 09:11:01"
}

What this means:

• Product ID 1 (product_dynamic_1) is being validated for quantity 1
• No quote item ID yet (null) - this is the initial validation before the item is added to cart
• Execution time: 0.037ms - very fast
• 0 database queries - excellent! No N+1 issue detected here
• This is the 1st validation in the session

Entry 2: Observer Conflict Detection

{
  "event": "sales_quote_item_collection_products_after_load",
  "product_count": 1,
  "execution_count": 1,
  "total_event_executions": 1,
  "likely_catalog_inventory_active": false,
  "likely_msi_active": false,
  "conflict_detected": false,
  "app_state": "developer",
  "memory_usage_mb": 46.0,
  "peak_memory_mb": 46.0
}

What this means:

• The sales_quote_item_collection_products_after_load event fired
• 1 product was processed in the collection
• Only 1 observer execution detected (good!)
• No conflict detected - both CatalogInventory and MSI observers are NOT running simultaneously
• Developer mode active
• Memory usage: 46MB - reasonable

Entry 3: Post-Addition Quantity Validation

{
  "product_id": "1",
  "product_sku": "product_dynamic_1",
  "quote_item_id": "171",
  "qty": 1.0,
  "execution_time_ms": 0.03,
  "queries_executed": 0,
  "validation_count": 1,
  "timestamp": "2025-09-11 09:11:03"
}

What this means:

• Same product being validated again
• Now has quote item ID 171 - the item has been successfully added to cart
• Still 0 database queries - excellent performance
• Execution time: 0.03ms - even faster

Please let us know if we missed anything.

Thanks

[engcom-Hotel]

Hello @MagePsycho,

We are still waiting for your inputs for the above comment.

Thanks

[senthilengg]

@engcom-Hotel In any case if manage stock is set to No then these Observer should do a early return to avoid overhead, so its better to address still checking a config and return to avoid N+1 risk

[engcom-Hotel]

Hello @senthilengg,

Thanks for your reply!

I request you to please elaborate the point and also let us know the steps to reproduce the issue.

Thank you

[engcom-Hotel]

Hello @senthilengg @MagePsycho,

We request you to go through with the above comment. We need some elaboration on the comment.

Thank you

[senthilengg]

@engcom-Hotel I got confused with inventory_catalog_preload_cache and just realised that its only relevant for Adobe commerce version and not opensource. This is the reason it wasn't reproducible in OS version. I am ok close this ticket @MagePsycho You may need to followup with Adobe Support, if thats ok then we can close this ticket.

[engcom-Hotel]

Thank you @senthilengg for your inputs.

@MagePsycho please confirm if we can close this issue.

[MagePsycho]

@senthilengg @engcom-Hotel Lets not close this issue. I will updated with more details.

[engcom-Hotel]

Sure @MagePsycho, please let us know if you are able to get the details to proceed further with this issue.