Redis master replica sync delay causes "Required parameter 'theme_dir' was not passed" error

[hyq-csi-001]

Preconditions and environment

• Reproduced in clean Magento version 2.4.7-p3
• Installing and configuring Redis master and slave

The settings file is as follows

-redis master-slave synchronization delay
Simulating master-slave delay
①Cancel master-slave synchronization

②Delete the db0 data from the slave database

Steps to reproduce

1. Administrator user login backend
2. Create a CMS block with any content

3. Create a CMS page and associate the content of the page with the block in step 2
4. Open the editing screen for the CMS page you created in step 3

Expected result

• The screen is displayed correctly and no error messages are displayed. Preview content correctly displays the contents of the CMS blocks embedded in the CMS page.

Actual result

• An error message appears. The contents of the CMS block embedded in the CMS page are not displayed.

Additional information

• Execution log：The error message "main.ERROR: Required parameter 'theme_dir' was not passed" is displayed.

After investigating why the cache was deleted immediately after it was created, we found that the main cause was most likely that Redis was in a master/slave configuration (similar to a replica of the DB we are currently using).

1. I added logging to the remove cache function to get a stack trace when the cache is deleted.

2. After obtaining the stack trace log, we were able to confirm that the cache was deleted by the \Zend_Cache_Core::save function (line 407) immediately after it was saved.

The condition $data != $data2 is to check the consistency of data after it has been saved to the cache. Specifically, the cache ID is used to re-read the cache and compare it with the original data.

As a result, the original data and the data read from the cache did not match, and the target cache was deleted.

After checking the logs, we found that $data2 (data obtained from the cache) read immediately after saving to the cache was NULL.

Therefore, we believe that the translation data was too large, which meant that the Redis master-slave synchronization was not completed in time after saving to the cache, and that NULL was returned when the data was read at that time.
(This is a similar phenomenon to the common DB replica environment, where if you SELECT immediately after INSERT, the value may not yet be reflected in the replica DB and NULL may be returned.)

• Logs for $data and $data2

$data

$data2

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 @hyq-csi-001. 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-November. 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.

[zzw890827]

We are experiencing the same issue: a newly created cache key in Redis is getting removed immediately after being saved.

After investigating the data flow, we found that the cache is saved using the underlying Zend_Cache_Core::save method. Specifically, on line 407, the cache key is removed because the condition on line 405 is met:

if ($data !== $data2)

We suspect this is due to Redis replication lag — the data might not have been fully synced between the primary and replica at the time of the comparison. When only a single Redis primary instance is used (no replicas), this issue does not occur.

At this point, we’re unsure whether this behavior is caused by Magento or is inherent to Zend Framework’s caching logic.

Would appreciate any insights or similar findings from the community.

[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 @hyq-csi-001,

Thanks for the report and collaboration!

We have tried to reproduce the issue in the latest development branch i.e. 2.4-develop but it seems we are unable to reproduce the issue with Redis (master-slave) configuration.

Request you to please try the same in the latest development branch and let us know if it is reproducible for you.

Thanks