Phalcon Redis Backend is duplicating the prefix for writing but not for reading
$di->set('viewCache', function () use ($config) {
$frontCache = new \Phalcon\Cache\Frontend\Output();
return new \Phalcon\Cache\Backend\Redis($frontCache);
});
When saving, it is: _PHCR_PHCRen_US but it is trying to read _PHCRen_US but that key doesn't exist.
it is the same (_PHCRview_PHCRviewen_US) while using a custom prefix.
Why in the first place there is that _PHCR? (extra question, not part of the bug) It should be possible to change this, but it is hardcoded in the zephir file.
I was debugging further, this is related to snowair/phalcon-debugbar because of $this->_backend->getLastKey(); allows to get an internal property directly that should be protected as indicated by the class but it is still publicly accessible and mutable. And later send a message save with this value.
The root of the problem can be tracked to https://github.com/phalcon/cphalcon/blob/master/phalcon/cache/backend/redis.zep#L158 where there is a mutation to the property in the get and https://github.com/phalcon/cphalcon/blob/master/phalcon/cache/backend/redis.zep#L191 where is other mutation to the same value. I guess the right expression would be let this->_lastKey = keyName, instead of lastKey.
Can you confirm this solution? @sergeyklay
Of course, it would be easier to not have this property at all and rely only on not mutable properties and methods' arguments for this kind of _pseudo-global DI states_. But this would be an api break.
I think the problem is in snowair/phalcon-debugbar not in the redis component of phalcon. The mutations of the key name happen during get/save/delete so they are consistent there.
In snowair/phalcon-debugger, however, this is semantically incorrect because the last key is not the key name, it's a phalcon's prefixed key name.
$keyName=$this->getLastKey();
If snowair/phalcon-debugbar wants to retrieve the keyName should do:
$keyName=substr($this->getLastKey(), 5);
@gguridi $this->getLastKey(); would be a misnomer in that case. The right name would be "->getInternallyPrefixedLastKey()" and getLastKey will not behave consistently with the other adapters. So snowair would have to either use an if (...= "redis") or the remove the support for other adapters.
Cc: @snowair
Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues
Most helpful comment
I was debugging further, this is related to snowair/phalcon-debugbar because of
$this->_backend->getLastKey();allows to get an internal property directly that should be protected as indicated by the class but it is still publicly accessible and mutable. And later send a messagesavewith this value.The root of the problem can be tracked to https://github.com/phalcon/cphalcon/blob/master/phalcon/cache/backend/redis.zep#L158 where there is a mutation to the property in the
getand https://github.com/phalcon/cphalcon/blob/master/phalcon/cache/backend/redis.zep#L191 where is other mutation to the same value. I guess the right expression would belet this->_lastKey = keyName, instead oflastKey.Can you confirm this solution? @sergeyklay
Of course, it would be easier to not have this property at all and rely only on not mutable properties and methods' arguments for this kind of _pseudo-global DI states_. But this would be an api break.