Details
-
Bug
-
Resolution: Fixed
-
High
-
2.5.2
-
None
-
Redis Persistence Cache
-
[3.0] - Sprint 8
Description
In the admin backend, wrong states can be cached when multiple users access the backend simultaneously.
The problem is that there is a small time frame from the invalidation of cache keys / tags, until the database transaction is committed.
In this time, a process that is executed in parallel, can restore the cache values to their previous state.
The issue can be reproduced using xdebug.
Steps for reproduction:
1. Log into the admin backend and navigate to a content object.
2. Click on edit.
3. Put a breakpoint in https://github.com/ezsystems/ezpublish-kernel/blob/7.5/eZ/Publish/Core/Repository/ContentService.php#L1550
(just before the transaction is commited in the publishVersion function) and publish the draft.
At this point, the cache for the object will have been invalidated, but the transaction is yet to finish.
4. In a second browser tab, visit the objects admin/view/content url.
Look at the versions tab.
This will show the old state of the object and populate the cache with the old values.
5. Resume execution of the halted process.
The transaction will finish and now, the state in the database will be different from the cache.
The versions tab will still show the published version as "draft under edit".
6. Trying to edit the draft will throw an error: "Argument 'Version' is invalid: status is not draft"
Depending on where you set the breakpoint, you can get different results / errors.
Attachments
Issue Links
- relates to
-
EZP-29899 Current Content version loading can end up loading wrong version under concurrency
-
- Closed
-