Skip to content

Use consistent exception logging format#5514

Draft
p-datadog wants to merge 2 commits intomasterfrom
claude-9/fix-exception-message-format
Draft

Use consistent exception logging format#5514
p-datadog wants to merge 2 commits intomasterfrom
claude-9/fix-exception-message-format

Conversation

@p-datadog
Copy link
Copy Markdown
Member

What does this PR do?

Standardizes exception logging across lib/datadog/ to use the consistent format #{e.class}: #{e} instead of various inconsistent patterns like e.message, e.class.name #{e.message}, or e.class}: #{e.message}.

This touches 59 files, but every change follows the same mechanical pattern — no logic changes, just formatting consistency.

Motivation:

Exception#to_s and Exception#message have different contracts in Ruby. Subclasses can override them independently, and to_s is the method Ruby calls during string interpolation ("#{e}"). Using e.message directly can produce different output than #{e} when a subclass overrides one without the other.

Similarly, e.class already returns a displayable class name via its own to_s, making the extra .name call redundant in string interpolation.

The codebase convention is #{e.class}: #{e}. This PR brings all logging call sites in line with that convention.

What was NOT changed (intentionally):

  • e.message used for constructing new exceptions (raise SomeError, e.message)
  • e.message used in data structures or API payloads (e.g., error_message: fields)
  • e.message in Core::Error.build_from (value object construction)
  • e.message in conditionals or comparisons
  • payload[:exception] = [e.class.name, e.message] (Rails convention)
  • Test files

Change log entry

None — internal cleanup, no customer-visible behavior change.

Additional Notes:

AI-assisted. All changes reviewed for correctness. Each change site was individually evaluated to confirm it's a logging context (not exception construction, data payload, or conditional logic).

How to test the change?

This is a logging format change only. Existing tests should continue to pass. The change can be verified by:

  • Confirming no e.message remains in logger calls under lib/datadog/
  • Reviewing the diff to confirm each change is in a logging context
  • Running the existing test suite

Replace `e.message` with `e` (via string interpolation) and
`e.class.name` with `e.class` in all logging contexts across
lib/datadog/.

The `to_s` and `message` methods on Exception have different contracts:
subclasses can override them independently, and `to_s` is the method
Ruby calls during string interpolation. Using `e.message` directly
can produce different output than `#{e}` when a subclass overrides
`to_s` without overriding `message`, or vice versa.

Similarly, `e.class` already returns a displayable class name via
`to_s`, making `.name` redundant in string interpolation contexts.

The codebase convention is `#{e.class}: #{e}`. This commit brings
all logging call sites in line with that convention.

Does not change:
- `e.message` used for constructing new exceptions (raise)
- `e.message` used in data structures or API payloads
- `e.message` in Core::Error.build_from (value object construction)
- `e.message` in conditionals or comparisons
- Test files

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@p-datadog p-datadog added the AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos label Mar 26, 2026
@github-actions github-actions bot added core Involves Datadog core libraries integrations Involves tracing integrations profiling Involves Datadog profiling appsec Application Security monitoring product tracing labels Mar 26, 2026
@pr-commenter
Copy link
Copy Markdown

pr-commenter bot commented Mar 26, 2026

Benchmarks

Benchmark execution time: 2026-03-26 20:32:55

Comparing candidate commit 5201f49 in PR branch claude-9/fix-exception-message-format with baseline commit aef62f2 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 46 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

The source code changed from `e.message` / `e.class.name e.message` to
`e.class: e` (which produces `ClassName: message`). Test expectations
that asserted on the old format now fail because the logged string
includes the exception class name with a colon separator.

- tags_spec.rb: expected "Oops..." → "StandardError: Oops..."
- component_spec.rb: expected /Test failure/ → /RuntimeError: Test failure/
  (3 tests: start, stop, update_on_fork)
- transport_spec.rb: expected /Timeout::Error Ooops/ → /Timeout::Error: Ooops/
  (space → colon+space between class and message)

Co-Authored-By: Claude <noreply@anthropic.com>
@datadog-datadog-prod-us1-2
Copy link
Copy Markdown

datadog-datadog-prod-us1-2 bot commented Mar 26, 2026

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
Patch Coverage: 44.44%
Overall Coverage: 95.14% (-0.01%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: a8cb256 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos appsec Application Security monitoring product core Involves Datadog core libraries integrations Involves tracing integrations profiling Involves Datadog profiling tracing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants