With table prefix enabled in app/etc/env.php visit Product/Category pages and you would receive error with raw sql with incorrect table names for store & eav_attribute causing the page to go into 500 error

[realadityayadav]

The prefix for store and eav_attribute table was not considered & caused a breaking change in the product and category page.

Description (*)

With table prefix enabled in app/etc/env.php visit Product/Category pages and you would receive error with raw sql with incorrect table names for store & eav_attribute causing the page to go into 500 error

Related Pull Requests

Fixed Issues (if relevant)

1. Fixes magento/magento2#<issue_number> No Issue created.

Manual testing scenarios (*)

1. Ensure there is a table prefix set
2. Have your Magento updated to 2.4.5-p1 and visit product/category page

Questions or comments

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

Resolved issues:

1. resolves [Issue] With table prefix enabled in app/etc/env.php visit Product/Category pages and you would receive error with raw sql with incorrect table names for store & eav_attribute causing the page to go into 500 error #36518: With table prefix enabled in app/etc/env.php visit Product/Category pages and you would receive error with raw sql with incorrect table names for store & eav_attribute causing the page to go into 500 error

[m2-assistant]

Hi @realadityayadav. Thank you for your contribution
Here are some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE,
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here

ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

For more details, review the Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests 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 Pull Requests 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.

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[Den4ik]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[Den4ik]

@magento run all tests

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[Den4ik]

@magento run Functional Tests EE

[magento-automated-testing]

The requested builds are added to the queue. You should be able to see them here within a few minutes. Please re-request them if they don't show in a reasonable amount of time.

[Den4ik]

✅ Approved

[engcom-Lima]

@magento create issue

[engcom-Lima]

Hi @realadityayadav ,

Thanks for your contribution and collaboration.

I havd tried to reproduce the issue in latest 2.4-develop with table prefix but issue is not reproducible to me. Below are the screenshot for your reference:
Env.php:

Frontend:

Admin product creation page:

Steps followed:

1. Installed magento 2.4-develop with table prefix and verified env.php.
2. Go to frontend then to product page.
3. In admin panel > Catalog > Catalog > Product (edit)

If something I am missing in steps to reproduce , kindly provide me the information. Also, try to test it in latest 2.4-develop Magento. and let us know if you are facing any issue.

Thanks

[hostep]

@engcom-Lima: if you use prefix test, it's expected that this line will fail because the table eav_attribute won't exist, the table will be called testeav_attribute in your case.
So you probably failed to trigger this particular code, or you accidentally still have an eav_attribute table in your database ...

[Den4ik]

@engcom-Lima could you share database structure. I'm agree with @hostep, looks like you have eav table in database. Anyway direct usage of table names in queries is potentially problematic code

[engcom-Lima]

Hi @hostep & @Den4ik ,

Thanks for your quick reply and support.

Below is the screenshot of the database structure for your reference:

[hostep]

Ok good, that means you are not triggering the code that gets modified in this PR, so try to figure out how to trigger that code or maybe @realadityayadav can give you more accurate steps?

[engcom-Lima]

Hi @realadityayadav ,

Thanks for your contribution and collaboration.

Please provide us more information inorder to reproduce the issue.

Thanks

[realadityayadav]

@hostep @engcom-Lima @Den4ik
This is the whole error log if the fix is not in place
https://pastebin.pl/view/3bd88db5

I am not able to exactly find out why this could be an issue in our env though and not in your testing coz the error is straightforward.

[engcom-Lima]

Hi @realadityayadav ,

Thanks for your contribution and collaboration.

I have tried to reproduce it on Magento2.4.5-p1 both in enterprise and community edition but issue is not reproducible. But code need to be further analysed. We will come back to you soon on this.

Thanks

[realadityayadav]

@engcom-Lima I tried to find more into the code and came across that
https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Elasticsearch/Model/ResourceModel/Fulltext/Collection/SearchResultApplier.php#L103

and it has data as follows
You can check this line in your use case to see if it is same or different

`

[0]=>

  | object(Magento\Framework\Api\Search\Document)#2410 (1) {
  | ["_data":protected]=>
  | array(2) {
  | ["id"]=>
  | string(4) "5282"
  | ["custom_attributes"]=>
  | array(1) {
  | ["score"]=>
  | object(Magento\Framework\Api\AttributeValue)#2469 (1) {
  | ["_data":protected]=>
  | array(2) {
  | ["attribute_code"]=>
  | string(6) "_score"
  | ["value"]=>
  | NULL
  | }
  | }
  | }
  | }
  | }

prepared from Elasticsearch Query response in Line https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/CatalogSearch/Model/ResourceModel/Fulltext/Collection.php#L464

I think in your case elasticsearch doesn't have enough data which causes no score index to return or somewhat?

@hostep @Den4ik

[engcom-Echo]

Hi @realadityayadav,

We have tried to reproduce the issue using steps mentioned in comment but we are not able to reproduce it.

Also we have checked the data mention in comment
Below are the printed data from https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Elasticsearch/Model/ResourceModel/Fulltext/Collection/SearchResultApplier.php#L103

We are not getting 500 error.

Can you please check once on 2.4-develop if issue exists?

[hostep]

There was recently a big refactor that happened in the area of the code that was affected by this PR. This refactor happened in scope of "ACP2E-748: Layered navigation filters don't work when show out of stock is enabled".
It looks like the problematic SQL code got removed in this refactor.

@realadityayadav: can you confirm this? That the problem is no longer there on the current 2.4-develop branch?

[realadityayadav]

Yes @hostep @engcom-Echo, The issue isn't reproducible on 2.4-develop so it seems to be fixed.
Closing this then.