Handle more extra attribute types when logging

[solnic]

Follow up after #2803

Before, this would not be logged with extra hash attributes, now it works:

Flat hash

Sentry.logger.info("Hello World", testing: "complex data", today: Date.today)

Nested hash

Sentry.logger.info("Hello %{who}", who: "World", nested: { testing: "complex data", today: Date.today })

---

Closes #2801

[sentry]

Bug: The rescue block in attribute_hash incorrectly returns the original non-serializable object, causing a crash later during final payload serialization.
_{Severity: CRITICAL | Confidence: High}

🔍 Detailed Analysis

When a non-serializable object is passed as an attribute to a LogEvent, the attribute_hash method attempts to serialize it with JSON.generate. This fails and is caught by a rescue block. However, the rescue block then returns the original, non-serializable object within the attribute hash. This hash is embedded in the event payload. When the transport layer later attempts to serialize the entire event envelope, JSON.generate is called again on the full payload, which now contains the non-serializable object. This second serialization attempt fails with an unhandled exception, preventing the event from being sent.

💡 Suggested Fix

In the rescue block of the attribute_hash method, instead of returning the raw non-serializable value, convert it to a string representation using a method like value.to_s or value.inspect. This ensures the value is always serializable before being added to the event payload.

🤖 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: sentry-ruby/lib/sentry/log_event.rb#L187-L190

Potential issue: When a non-serializable object is passed as an attribute to a
`LogEvent`, the `attribute_hash` method attempts to serialize it with `JSON.generate`.
This fails and is caught by a `rescue` block. However, the `rescue` block then returns
the original, non-serializable object within the attribute hash. This hash is embedded
in the event payload. When the transport layer later attempts to serialize the entire
event envelope, `JSON.generate` is called again on the full payload, which now contains
the non-serializable object. This second serialization attempt fails with an unhandled
exception, preventing the event from being sent.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8030622}

[solnic]

This is fine, previously it would crash too but at the transport level which now works when we can convert to JSON.

[dingsdax]

lgtm!

If you use JSON.parse with symbolize_names: true than there is no need to change that many lines in the tests, not sure what's best there.

Is there a way to support better nested attributes in the UI, is any SDK capable of this @sl0thentr0py ?

[sl0thentr0py]

I'm not sure JSON.generate is the right thing to do here, python just does the equivalent of object.to_s in the fallback case. I'll get back on this after investigating.

[dingsdax]

I'm not sure JSON.generate is the right thing to do here, python just does the equivalent of object.to_s in the fallback case. I'll get back on this after investigating.

🤔 to_s is lossy and does not guarantee returning a string and afaik almost never raises.

[solnic]

@sl0thentr0py I thought Python has identical behavior (and IIRC javascript too)

[solnic]

If you use JSON.parse with symbolize_names: true than there is no need to change that many lines in the tests, not sure what's best there.

I decided to stick to just generate as it's probably faster than symbolizing too.

Is there a way to support better nested attributes in the UI, is any SDK capable of this @sl0thentr0py ?

Unfortunately it is not supported yet, from our docs:

attributes
Array, optional. A dictionary of key-value pairs of arbitrary data attached to the log. Attributes must also declare the type of the value. The following types are supported: string, number, boolean, integer, double.

[dingsdax]

thanks