-
Notifications
You must be signed in to change notification settings - Fork 9.4k
[2.4.4] Missing Frontend CacheInfo breaks bin/magento #35812
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @Hexmage. Thank you for your report.
Make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:
For more details, review the Magento Contributor Assistant documentation. Add a comment to assign the issue: To learn more about issue processing workflow, refer to the Code Contributions.
🕙 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. ✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel |
Hi @engcom-Delta. Thank you for working on this issue.
|
Hi @Hexmage , Please find the attached reference video. |
@Hexmage I just had this issue, I initially tried the fix you suggested but it still reported errors for me. I got to the root for my instance, we use LiteSpeed cache and when I looked in the admin panel it had dropped back to built in cache (I commented out lines 89-91 of pool.php temporarily). The culprit was somehow our .htaccess was missing this:
When I added this the cache setting selection had reverted back to Litespeed without me reselecting it. |
@devchris79 Then I probably know what it was. My staging and live environments run on Varnish. But my develop environment doesn't. But I had synced the config from my staging to my develop environment. So the real issue is that if a caching method is selected in the configuration that can't work it throws a very awkward error. |
@Hexmage It would certainly seem that is the case. I am guessing the data provider function getConfigData isn't retrieving an intended null. Maybe the data array element is there but with invalid elements within the config.
|
@Hexmage Do you now have an additional entry in your env.php? , |
@Hexmage I think your original fix is what's required, I think that I had two issues going on at the same time with Litespeed cache loss provoking your issue. |
I did change the line in pool.php as described here . syntax error, unexpected '{'#0 /home/user222/domains/xxxxxx.xx/public_html/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile('/home/u58658p55...') |
@richardreen, I think @Hexmage has a small error from his suggested fix below, he is missing a closing bracket from the if statement:
Try this instead: |
oke, corrected it and now it runs...no error about syntax error anymore. |
now presenting a new error: and the salt entry still added to env.php |
That issue with a fix is here: #35412 |
after correcting that, the next error {"errors":[{"message":"Syntax Error: Unexpected ","extensions":{"category":"graphql"},"locations":[{"line":1,"column":1}]}]} and 500 error and salt...in the env.php.. |
Hi @Hexmage , Thanks |
@engcom-Delta |
Hi @Hexmage , Regards, |
@engcom-Delta |
Hi @engcom-Dash. Thank you for working on this issue.
|
Hi @Hexmage, We are checking the issue with 2.4-develop instance and we are not able to reproduce the issue because we are getting expected result.... Steps: Let us know if we missing anything!!! Thanks!!! |
@engcom-Dash Did you configure Varnish on the server before upgrade but don't actually have varnish installed? This is what I believe results in the error. Also it only showed when running bin/magento |
@magento give me 2.4-develop instance |
@magento give me 2.4-develop instance |
@magento give me 2.4-develop instance |
Hi @engcom-Dash. Thank you for your request. I'm working on Magento instance for you. |
Hi @engcom-Dash, here is your Magento Instance: https://a0c7ab63ae156afb6b38ad4d58baf5ee.instances.magento-community.engineering |
Hi @Hexmage , As per your instructions we enabled varnish on the server before upgrade...Even though we getting the same results. Let us know if we missing anything!!! Thanks! |
@engcom-Dash |
Hi @Hexmage , We tried both Local and cloud instance we are same results...Any how we will try once with fresh installation and will update you ASAP. Thanks!!! |
@engcom-Dash
Because there is a graphql node it automatically also expects there to be a frontend node, which isn't always true. |
@engcom-Dash |
Hi @devchris79 , We are Closing this issue seems its like duplicate https://github.com/magento/magento2/issues/35861 Let us know if we missing anything!!! Thanks! |
@engcom-Dash We have a Magento 2.4.4-p2 and can reproduce the problem just my calling the "/graphql" URL of the store. This adds the "id_salt" value into the I'm confused: this issue was closed with the reason that it's a duplicate of #35861, but #35861 itself is also closed. So no one is working on this at all? |
In magento 2.4.5 this error is not thereanymore
Verstuurd vanaf mijn iPad
… Op 7 nov. 2022 om 15:54 heeft Michael ***@***.***> het volgende geschreven:
@engcom-Dash We have a Magento 2.4.4-p2 and can reproduce the problem just my calling the "/graphql" URL of the store. This adds the "id_salt" value into the env.php and afterwards the frontend returns only http-500. On the other side we could not reproduce this behaviour with Magento 2.4.3. Sounds like a serious problem to me.
I'm confused: this issue was claused with the reason that it's a duplicate of #35861, but #35861 itself is also closed. So no one is working on this at all?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Just happened to me on 2.4.5-p1, problem is still there |
I had this issue also with 2.4.5-p1. GraphQL (1:1) fixed temporarily remove the hash from env.php |
Found out the reason, it happens if the env.php does not have the cache -> frontend node. After the cache configuration was added correctly the issue does not appear anymore. |
@engcom-Dash So if your This is caused because the call to the graphql endpoint creates a |
I just started encountering this issue on a fresh 2.4.6-p1 build. Hitting the /graphql/ url kills the site. Short of installing Varnish and enabling cache to get the needed node inserted into env.php, does someone have the snippet of code for env.php that would prevent this error from happening? |
There might already be a different value in the |
Ran into this using Magento 2.4.6-p3 I don't understand why this issue got closed though. @engcom-Dash: it got closed because it's a duplicate of #35861 and #35861 got closed because it's a duplicate of this issue, that makes little sense? One of both should remain open, otherwise it can't be picked up. Or has it already been fixed on |
Okay, dug in a bit. This probably only happens for shops that were first setup with a version before Magento 2.3.1, and that later got updated to a newer version (needs to be at least 2.4.4). Before 2.3.1, this change wasn't included yet, which writes And the code mentioned before crashes because it expects a A good fix in my opinion is to run
However, we still need to fix this crash that can happen, will send in a PR shortly with a fix. |
Preconditions and environment
Steps to reproduce
composer update --no-dev
Run bin/magento.
Expected result
See a list of commands.
Actual result
Warning: Undefined array key "frontend" in ../vendor/magento/framework/App/Cache/Frontend/Pool.php on line 90
Additional information
I have no clue what causes the exact scenario to start happening. But it appears that it's a minor programming oversight. Where someone assumed that if cacheInfo exists, the frontend cacheInfo also exists which apparently isn't true.
Fix is changing line 89 from
if (null !== $cacheInfo) {
to
if (null !== $cacheInfo && isset($cacheInfo[FrontendPool::KEY_FRONTEND_CACHE]) {
Release note
No response
Triage and priority
The text was updated successfully, but these errors were encountered: