Database columns are not properly cached and lead to mass email sending during cron execution about magento-lts HOT 7 CLOSED

Probably needs more info, like

OpenMage version, Mysql Server version (any different settings?) etc.

from magento-lts.

Oh. I am sorry, I put those in but then re-arranged the whole post.
This installation is nothing special disregarding the fact, that it is currently broken :D

from magento-lts.

Whats the exact mysql error your database complains?

from magento-lts.

UPDATE core_email_queue SET WHERE (message_id='23912')

Set-part is empty?

from magento-lts.

I'm on the main branch, php82, mysql8, caches all enabled (also with all disabled I've the same behaviour), 3 mails in core_email_queue:

after running cron.php they get marked as processed:

from magento-lts.

I tried to replicate this issue without any luck, using a fresh instance of the following

Windows 10, DDEV + WSL (Apache + PHP 8.2 + MariaDB)
OpenMage 20.1.0-rc7 (using git clone)
Magento Sample Data (using ddev openmage-install)

I truncated before running the tests both cron_schedule and core_email_queue tables. I placed an order. Cron is running then the email is triggered by MailHog

This is a screenshot related to the table content. The request was processed (the last column).

Possible solutions, taking in consideration the OpenMage file system is untouched:

1. Empty the table core_email_queue (TRUNCATE), or
2. Delete the table core_email_queue and re-create it

If not working you have missing or modified files. As Sven pointed out above the query is wrong.

Syntax error or access violation: 
1064 You have an error in your SQL syntax; check the manual that 
corresponds to your MySQL server version for the right syntax to use near
'WHERE (message_id='23912')' at line 1, 
query was: UPDATE `core_email_queue` SET  WHERE (message_id='23912')

UPDATE statement has this syntax

UPDATE table_name
SET column1 = value1, column2 = value2, ...
WHERE condition;

In your case SET has missing arguments.

from magento-lts.

I found it out. And I am really sorry to have wasted your time.

The key information here is actually really something I added kinda ironically.

Maybe hosting at Mittwald.de 🤷

They have an Apache2 + FPM setup. Mix in a little OPCache inside there and a symlink release setup.

Old release: current -> release-18
New release: current -> release-19

Apache2 coming in being configured to go to current.
The error log of the cron was not a good insight.
The error log of the web requests gave more insight (with other exceptions):

#13 */html/release-19*/webroot/app/..... 
#14 */html/release-18*/webroot/index.php(88): Mage::run($mageRunCode, $mageRunType);

As we see here, the request starts inrelease-18 and then moves onward to release-19.
The opcache then bounced around between 18 and 19.
The cache got rewritten at times, but it was obviously not compatible with each other, which lead to the broken sql query.

The core_email_queue was properly the only table that got used by the cron and the web application and therefor caused this catastrophic behavior.

After clearing the opcache with opcache_reset() within the FPM process, it worked properly. And also every other exception in the log disappeared (including those I have mentioned here: #3381 (comment)) WHY?!?!? Idk :D Maybe the new OpenMage version handles those exceptions differently now.

So, what have we learned:

• If you release a new version of your software: clear the opcache (fpm reload, cachetool, whatever)
• Try to use the realpath when communicating with FPM, not weird symlinks
  • This is not really possible with Apache
  • With nginx use $realpath: fastcgi_param SCRIPT_FILENAME $realpath_root/[filename]
• Follow your ironically added information, if they seem like a solid hint :D

Regarding the cache structure change
I jumped from OpenMage 19.4.15 to 19.5.0-rc5.
In between those releases the file cache structure seems to have changed.

Since the cache is usually not required to sustain over releases, is it not considering this to be a breaking change, which should be version 20? 🤔

from magento-lts.