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

ClientSetInfo adds runtime.Version() to libName #2914

Closed
Woutifier opened this issue Feb 19, 2024 · 1 comment · Fixed by #2915
Closed

ClientSetInfo adds runtime.Version() to libName #2914

Woutifier opened this issue Feb 19, 2024 · 1 comment · Fixed by #2915

Comments

@Woutifier
Copy link

ClientSetInfo adds the output of runtime.Version() to the libName. The runtime.Version() is not guaranteed to not contain characters not allowed by redis. For example in our case it is: go1.22.0 X:boringcrypto, and spaces are not allowed in libName.

The only way to prevent this is to set DisableIndentity (presumably a typo from DisableIdentity). However, if you are also using Sentinel then that option is not copied over in sentinelOptions so you'll always send the illegal libName.

sentinel.go:552: sentinel: GetMasterAddrByName master="default" failed: ERR LIB-NAME cannot contain spaces, newlines or special characters.
libName = go-redis(,go1.22.0 X:boringcrypto)

Expected Behavior

It shouldn't matter what the go version string is when connecting to a redis server.

DisableIndentity should prevent it from being sent in all cases

Current Behavior

It matters what the go version string is, potentially breaking when that string is illegal in libName

DisableIndentity does not always prevent libName from being sent (e.g. Sentinel).

Possible Solution

Remove the Go version from the libName, or strip illegal characters from it. Also copy disableIndentity in all relevant places.

Steps to Reproduce

Build a redis client program using a Go version that has a version string with a space in it

@Woutifier
Copy link
Author

Presumably this was failing earlier (in 9.4.0) as well except any error was ignored, that behavior changed when the ClientSetInfo calls were moved into the pipeline.

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

Successfully merging a pull request may close this issue.

1 participant