We recently encountered a scenario on a project where two simultaneous REST API calls updated post meta on the same post.
The updates themselves were saved to the database without an issue. However, we observed that when the slower of the two requests attempted to clear the post_meta cache for the post, the del request to Redis would fail. We assume it failed because the faster of the two requests had already deleted the same key after its post meta updates.
The slower of the two requests would then attempt to respond to the client with the updated list of post meta, but the response wouldn't include any of the newly saved post meta: After the del request failed, the subsequent call to _unset_internal() wouldn't be reached, and the stale "internal" data would be reused on the next call to get_post_meta():
|
if ( 1 !== $result ) { |
|
return false; |
|
} |
|
} |
|
|
|
$this->_unset_internal( $key, $group ); |
This scenario seems like it could be avoided by moving _unset_internal() to before the call to Redis, and making it unconditional. In our specific scenario, I think it would have prevented stale data from being returned to the client, assuming we diagnosed what happened accurately.
More generally, I think it would reflect the developer's intention more accurately because the deletion request would be reflected in at least one cache layer — the in-memory cache — even if the deletion wasn't reflected in Redis because there was an actual problem deleting the key there.
I'm happy to submit a PR if this suggestion seems sensible.
We recently encountered a scenario on a project where two simultaneous REST API calls updated post meta on the same post.
The updates themselves were saved to the database without an issue. However, we observed that when the slower of the two requests attempted to clear the
post_metacache for the post, thedelrequest to Redis would fail. We assume it failed because the faster of the two requests had already deleted the same key after its post meta updates.The slower of the two requests would then attempt to respond to the client with the updated list of post meta, but the response wouldn't include any of the newly saved post meta: After the
delrequest failed, the subsequent call to_unset_internal()wouldn't be reached, and the stale "internal" data would be reused on the next call toget_post_meta():wp-redis/object-cache.php
Lines 609 to 614 in 2fa07d3
This scenario seems like it could be avoided by moving
_unset_internal()to before the call to Redis, and making it unconditional. In our specific scenario, I think it would have prevented stale data from being returned to the client, assuming we diagnosed what happened accurately.More generally, I think it would reflect the developer's intention more accurately because the deletion request would be reflected in at least one cache layer — the in-memory cache — even if the deletion wasn't reflected in Redis because there was an actual problem deleting the key there.
I'm happy to submit a PR if this suggestion seems sensible.