-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using front-end API is bugged on azure deployments #229
Comments
think about things that change on OSes. "keys", like strings, have case sensitivity, encodings, etc. timestamps / dates have different timezone assumptions. other than that there's actually almost no detail here at all. "using RedisInsight on macOS Monterey." - is this...the client? or running redis server also? "azure" - what kind of redis do they host? I have no idea. "did not work" - what does that mean? core dump ? stack trace? wrong data ? overall, azure's a hosted environment and mac OS is not, so we would assume something changes about redis server and/or client. wouldn't be a dogpile issue directly. |
Thanks for responding so quickly! I'm looking into getting you some more information 👍 |
To give a bit of clarification on the code itself, the following is a simplified version of what did not work:
The following is a simplified version of what did work:
Elsewhere in the code, our functionality was something akin to the following:
A good thing to be aware of, but I believe redis keys are binary safe... ?
Admittedly true. The thought about this issue is that the deployment environment was consistent between what did not work and what did work (leading to the thinking that there might be a bug)
Unfortunately, we were not aware of any details regarding specifics (no traces/dumps), other than we weren't getting the data we expected.
This was just the client, and a line-by-line debugging session indicated that the redis db was, indeed, clearing the specified key before getting some new data.
Admittedly, I do not either. Our dockerfile mentions using debian:11 with postgresql13 and python 3.9 |
We established a cache using the redis backend and used the front-end to explicitly define keys using...
CacheRegion.set(key: str, value: Any)
If a region does not have a key set (checked using
CacheRegion.get(key, expiration_time=None, ignore_expiration=False)
a value is set before being returned, as in the following:There was separate code that explicitly deleted specific keys using
CacheRegion.delete(key: str)
. Think "separate UI that is manually able to purge the specific cache-key on-demand". Functionality worked and was verified using RedisInsight on macOS Monterey.☝️ This implementation did not work for an unknown reason on deployment in azure
When the same logic was implemented using
cache_on_arguments
withinvalidate
, with a region that used afunction_key_generator
, the implementation worked on azure deployments. Furthermore, log messages were seen in the process output (which wasn't seen before using the front-end API).Not sure what the issue was. Feel free to ask for more info.
The text was updated successfully, but these errors were encountered: