-
Notifications
You must be signed in to change notification settings - Fork 232
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
tracing: fix DHT keys as string attribute not being valid utf-8 #859
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just debug info but I'm not sure this is what we want here.
I would either always encode it or never do it, not smartly depending on if it's valid utf8 or not.
Ok nvm, having the conditional is fine, let's still use a multibase to encode it. |
func KeyAsAttribute(name string, key string) attribute.KeyValue { | ||
b := []byte(key) | ||
if utf8.Valid(b) { | ||
return attribute.String(name, key) | ||
} | ||
encoded, err := multibase.Encode(multibase.Base58BTC, b) | ||
if err != nil { | ||
// should be unreachable | ||
panic(err) | ||
} | ||
return attribute.String(name, encoded) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really like that we always run this code, even if we are not tracing. Might be something to do by returning an fmt.Stringer
that lazily do this, however I belive otel always execute stringers anyway. The DHT is not very CPU efficient nor hot anyway so that fine, if it becomes not in profiles we should hoist this in some reusable package, send PR to lazily stringify in otel and return an fmt.Stringer.
Suggested version: Changes in (empty)
Automatically created GitHub ReleasePre-creating GitHub Releases on release PRs initiated from forks is not supported. |
Fix #858