-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
chore: use an equivalent fixed column for tag attributes #5028
base: develop
Are you sure you want to change the base?
Changes from all commits
9c8e750
5d8c2f7
d05d906
74e8d22
3170c34
12223e0
caef0ae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -85,18 +85,17 @@ func getClickhouseTracesColumnDataTypeAndType(key v3.AttributeKey) (v3.Attribute | |
} | ||
|
||
func enrichKeyWithMetadata(key v3.AttributeKey, keys map[string]v3.AttributeKey) v3.AttributeKey { | ||
if key.Type == "" || key.DataType == "" { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess what breaks with removing this is when there is an attribute different type or datatype, irrespective of what user explicitly selects their preferred type and datatype, we override? I am not sure how much of a real problem this is. I have come across any customer who had the same attribute name with a different type or data type. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That might be an issue but only when user is using custom attribute key with same name as otel key. I haven't encountered any users with the same attribute name and different types. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There are a few users with the same key but different type/data type and they are not necessarily because of the custom attribute collision with otel key. See #5150 & #5359; @nityanandagohain created the issue after a bug request from a customer and then oss user also added that they are impacted by it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, I saw community user faced the issue. Let's block this until we find a fix There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. They are independent problems, aren't they? Could we modify this pull request to still honor the user's selection (assuming the request payload is accurate), but for the attributes we know have fixed columns, use those instead? |
||
// check if the key is present in the keys map | ||
if existingKey, ok := keys[key.Key]; ok { | ||
key.IsColumn = existingKey.IsColumn | ||
key.Type = existingKey.Type | ||
key.DataType = existingKey.DataType | ||
} else { // if not present then set the default values | ||
key.Type = v3.AttributeKeyTypeTag | ||
key.DataType = v3.AttributeKeyDataTypeString | ||
key.IsColumn = false | ||
return key | ||
} | ||
// check if the key is present in the keys map | ||
if existingKey, ok := keys[key.Key]; ok { | ||
key.Key = existingKey.Key | ||
key.IsColumn = existingKey.IsColumn | ||
key.Type = existingKey.Type | ||
key.DataType = existingKey.DataType | ||
} else if key.Type == "" || key.DataType == "" { // if not present then set the default values | ||
key.Type = v3.AttributeKeyTypeTag | ||
key.DataType = v3.AttributeKeyDataTypeString | ||
key.IsColumn = false | ||
return key | ||
} | ||
return key | ||
} | ||
|
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.
Since the equivalent change in collect is recent and not released yet, we either have to hold this PR for enough data to backfill or just comment out these new additions so users don't see incorrect results for longer time ranges.