Skip to content
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

[BUG] Memory metric db.dict.rehashing.count breaks older clients #1598

Open
JimB123 opened this issue Jan 21, 2025 · 3 comments
Open

[BUG] Memory metric db.dict.rehashing.count breaks older clients #1598

JimB123 opened this issue Jan 21, 2025 · 3 comments

Comments

@JimB123
Copy link
Contributor

JimB123 commented Jan 21, 2025

Describe the bug

Using the MEMORY STATS command, older clients use db.x to recognize a substructure related to a specific database. Like db.0 has values containing overhead.hashtable.main and overhead.hashtable.expires.

Unfortunately, a new metric named db.dict.rehashing.count breaks older clients due to the prefix of db.. This makes it impossible to execute MEMORY STATS from these clients.

Specifically, in python-redis, in function parse_memory_stats, a line of code was changed:

        if key.startswith("db."):                              # OLD
        if key.startswith("db.") and isinstance(value, list):  # NEW

Recommend renaming this metric to avoid the use of db. as a prefix.

To reproduce

Use an older version of python-redis and execute: client.memory_stats(). It will throw an exception.

Expected behavior

No exception

@JimB123
Copy link
Contributor Author

JimB123 commented Jan 21, 2025

Also recommend adding a test which executes MEMORY STATS to prevent future similar issues.

@enjoy-binbin
Copy link
Member

Recommend renaming this metric to avoid the use of db. as a prefix.

Sadly changing this is a breaking change...

@madolson
Copy link
Member

madolson commented Jan 22, 2025

Yeah, it was also a change we inherited from Redis: redis/redis#12913. I'm not sure we can easily diverge at this point. It's probably we could we remember this to avoid doing this in the future, but I agree I think we need to keep it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants