Table 'magento.catalog_product_index_price_temp' doesn't exist

[defenseoftheancients]

Preconditions and environment

• Magento version: 2.4.7-p3
• PHP: 8.3
• MariaDB: 10.6

Steps to reproduce

Execute the following CLI command:

php bin/magento indexer:reindex

Expected result

• System indexes should be rebuilt successfully without errors.

Actual result

1. The following errors occur during the indexation process:

• Product Price Index: Fails due to a child process error.

• Catalog Search Index: Fails due to a child process error.

2. The debug.log file contains the following error message:
   Base table or view not found: 1146 Table catalog_product_index_price_temp' doesn't exist, query was: SELECT i.entity_id, o.option_id FROM catalog_product_index_price_temp AS i INNER JOIN catalog_product_entity AS e ON e.entity_id = i.entity_id INNER JOIN catalog_product_option AS o ON o.product_id = e.entity_id

Additional information

The issue originates in the CustomOptionPriceModifier::getConnection method:

 if (null === $this->connection) {
     $this->connection = $this->resource->getConnection($this->connectionName);
 }

(see \Magento\Catalog\Model\ResourceModel\Product\Indexer\Price\CustomOptionPriceModifier::getConnection)

Root Cause Analysis:

1. The Inventory index runs and triggers the PriceIndexUpdatePlugin plugin: \Magento\InventoryCatalog\Plugin\InventoryIndexer\Indexer\Stock\Strategy\Sync\PriceIndexUpdatePlugin
2. During this process, $this->connection is assigned a value.
3. When the Product Price index runs

(see: Magento\Catalog\ResourceModel\Product\Indexer\Price\SimpleProductPrice)

• A temporary table (catalog_product_index_price_temp) is created at line 69.
• The CustomOptionPriceModifier::getConnection method is triggered at line 100
• Because $this->connection is already set (from the Inventory index), it reuses this connection
• The query fails because the temporary table does not exist in this reused connection.

I modify the getConnection method to always establish a new connection instead of reusing the previous one and and the issue was resolved:

private function getConnection()
{
    // Remove the condition to reuse the connection
    $this->connection = $this->resource->getConnection($this->connectionName);
    return $this->connection;
}

Release note

No response

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @defenseoftheancients. 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.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 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]

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: 👇

• 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 @defenseoftheancients,

Thanks for the report and collaboration!

We have tried to reproduce this issue in the latest development branch i.e. 2.4-develop with the following configuration:

• PHP 8.4
• MariaDB 11.4

But it seems the issue is not reproducible for us. Please refer to the below screencast for the reference:

Table-magento-catalog_product_index_price_temp-doesn-t-exist-.-Issue-39664-.-magento-magento2.webm

Please let us know if we missed anything.

Thanks

[engcom-Hotel]

Hello @defenseoftheancients,

We are still waiting for your reply on this issue.

Thanks

[defenseoftheancients]

Hello @defenseoftheancients,

We are still waiting for your reply on this issue.

Sorry for the late reply.
I tried reinstalling a fresh Magento 2 site and created a new product. In each section of the product edit page in the admin panel, I filled in the values, saved the product, and ran the reindex command after each step. When I reached the Sources section, I discovered that the issue occurs only when assigning the product using an MSI (Multi-Source Inventory) stock instead of the Default Stock.
Let me know if you'd like me to provide a video to demonstrate the issue.

[defenseoftheancients]

The issue occurs only when using 'Update on Save'

[engcom-Hotel]

Hello @defenseoftheancients,

Thanks for the update!

We have tried further to reproduce the issue, but still the issue is not reproducible for us. Please refer to the below screenshot and screencast for the reference:

2-min.mp4

Let us know if we missed anything.

Thanks

[defenseoftheancients]

Thank you for checking again. I’ve recorded a video to demonstrate the issue I’m encountering.

Please refer to the following timestamps in the video:

• 00:00 – 01:46: Fresh installation of Magento.
• 01:46 – 02:10: Running the reindex command in "Update by Schedule" mode.
• 02:11 – 03:13: Creating and saving a new product assigned to the Default Stock.
• 03:14 – 04:12: Creating a custom source and stock, and switching index mode to "Update on Save".
• 04:13 – End: Assigning the product to the custom MSI stock, unassigning it from Default Stock, saving the product, and running the reindex command.

Video: https://vimeo.com/1082225746

Let me know if you need any additional details to help reproduce the issue.

[engcom-Hotel]

Hello @defenseoftheancients,

I truly appreciate your effort here, and we have again tried to reproduce the issue in the latest development branch i.e. 2.4-develop but the issue is not reproducible for us. Please refer to the attached screencast for reference:

4-min.mp4

It might be possible the issue has been resolved in the latest development branch hence we request you to please try to reproduce the issue in the latest stable release and let us know if you are still able to reproduce the issue.

Thanks

[defenseoftheancients]

I’ve tested the issue again using the 2.4-develop branch and was still able to reproduce it. I’ve recorded a video demonstrating the steps and the issue in this version as well.

Please refer to the following timestamps in the video:

• 00:00 – 05:21: Fresh installation of Magento 2.4-develop
• 05:21 – End: Step-by-step process to reproduce the issue

Video link: https://vimeo.com/1082579063?share=copy

To ensure it's not environment-specific, I also tried a fresh installation using a different Docker setup (markshust/docker-magento), but the error still persists.

Please let me know if you need any additional information or environment details to help investigate further.

[engcom-Hotel]

Hello @defenseoftheancients,

Thanks for the updates!

But as the issue is not reproducible for us with the below environment:

• MacOS
• PHP 8.4
• Apache
• Opensearch 2.19.2

Please let us know additional information if you have with the environment details.

Thanks

[defenseoftheancients]

Thank you for the update.

To match your testing environment, I set up a fresh Magento 2.4-develop installation using the following configuration:

• macOS

• PHP 8.4

• Apache

• OpenSearch 2.19.2

Despite matching the environment, I was still able to reproduce the issue. I’ve recorded a new video showing the steps and the issue occurring under these conditions.

Video link: https://vimeo.com/1083104008?share=copy#t=0

---

If this still isn’t considered a valid issue from your side, I’m okay with closing it. Just wanted to ensure I shared all possible details to help clarify the situation.

Thanks again for your time and support.