-
-
Notifications
You must be signed in to change notification settings - Fork 198
feat(logs): custom attributes API #1435
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
base: master
Are you sure you want to change the base?
Conversation
|
e1f307a to
1ea83a8
Compare
examples/example.c
Outdated
| sentry_value_set_by_key( | ||
| param_attributes, "message.parameter.0", param_attr); | ||
| sentry_value_set_by_key( | ||
| param_attributes, "sentry.sdk.name", param_attr_2); | ||
| // TODO discuss; param_attributes[message.parameter.0] gets overwritten | ||
| // by 'and format string'. Is this expected? | ||
| sentry_log_fatal("logging with a custom parameter %s attributes", | ||
| param_attributes, "and format-string"); |
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.
IMO we can overwrite all default attributes except for string format values that are passed in; otherwise there would be a mismatch between the string template + sentry.message.parameter.X and the log body value
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 think using both the attributes to pass message.parameter.0 and the sentry-native interpolation API is already a misuse. I don't think we need to be protective about it. Let it be an undefined behavior.
| if (sentry_value_get_type(custom_attributes) | ||
| == SENTRY_VALUE_TYPE_OBJECT) { | ||
| // TODO do we want to inspect that the object is attribute-like? | ||
| sentry_value_decref(attributes); | ||
| attributes = sentry__value_clone(custom_attributes); | ||
| } else { |
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'm not sure how far we need to go to protect from user error. An invalid attribute (no "type" and "value" keys) seems to just get ignored in processing (the log still makes it to the UI)
|
@sentry review |
| sentry_value_t log = sentry_value_new_object(); | ||
| sentry_value_t attributes = sentry_value_new_object(); | ||
|
|
||
| va_list args_copy_1, args_copy_2, args_copy_3; | ||
| va_copy(args_copy_1, args); | ||
| va_copy(args_copy_2, args); | ||
| va_copy(args_copy_3, args); | ||
| int len = vsnprintf(NULL, 0, message, args_copy_1) + 1; | ||
| va_end(args_copy_1); | ||
| size_t size = (size_t)len; | ||
| char *fmt_message = sentry_malloc(size); | ||
| if (!fmt_message) { | ||
| SENTRY_WITH_OPTIONS (options) { | ||
| // Extract custom attributes if the option is enabled | ||
| if (sentry_options_get_logs_with_attributes(options)) { | ||
| va_list args_copy; | ||
| va_copy(args_copy, args); |
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.
The removal of the fallback sentry.sdk.name attribute (previously added unconditionally) is now handled by the add_attribute() no-op behavior when custom attributes override it. However, verify that in the non-custom-attributes path, sentry.sdk.name is still being added consistently by add_scope_and_options_data(). The logic depends on add_attribute() being called with sentry.sdk.name from somewhere else in the flow.
Severity: MEDIUM
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/sentry_logs.c#L647-L680
Potential issue: The removal of the fallback `sentry.sdk.name` attribute (previously
added unconditionally) is now handled by the `add_attribute()` no-op behavior when
custom attributes override it. However, verify that in the non-custom-attributes path,
`sentry.sdk.name` is still being added consistently by `add_scope_and_options_data()`.
The logic depends on `add_attribute()` being called with `sentry.sdk.name` from
somewhere else in the flow.
Did we get this right? 👍 / 👎 to inform future reviews.
| @@ -708,14 +744,6 @@ | |||
| // to the log | |||
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.
The entire message formatting and parameter parsing logic is now wrapped inside SENTRY_WITH_OPTIONS. While this ensures thread-safe access to options, it's a behavioral change from the original implementation. Verify that the lock scope doesn't negatively impact performance for high-frequency logging scenarios, and consider documenting why this lock scope is necessary.
Severity: MEDIUM
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/sentry_logs.c#L679-L744
Potential issue: The entire message formatting and parameter parsing logic is now
wrapped inside `SENTRY_WITH_OPTIONS`. While this ensures thread-safe access to options,
it's a behavioral change from the original implementation. Verify that the lock scope
doesn't negatively impact performance for high-frequency logging scenarios, and consider
documenting why this lock scope is necessary.
Did we get this right? 👍 / 👎 to inform future reviews.
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.
There is no exclusive lock over the options, since we only increment the refcount (and the options themselves are read-only). So there is no real performance impact here.
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.
LGTM 🙃


fixes #1405
With the
logs_with_attributesoption set to true, we can still parse the message string as a format string, but we take the first varg passed intosentry_log_Xas an attributes object.If the passed-in value is not a
sentry_value_tobject, we will just ignore it (as long as it is still asentry_value_ttype, otherwise we hitUNREACHABLE("invalid value type");when trying to parse it)Which shows up in the UI as such:
This is also useful for downstream SDKs which might not need string interpolation, but still want to pass down message.parameter.X attributes:
sentry.message.parameter.Xvalues; if you pass in a string with format specifiers, these are used for the message parameter values.--> the custom-sdk-name shows up, but the

sentry.message.parameter.0value is"and format-string", not"parameter".