Skip to content

feat(tracer): add recordException API #6010

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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

dubloom
Copy link

@dubloom dubloom commented Jul 2, 2025

What does this PR do?

  • Adds recordException API following this RFC. recordException attaches error information to span through a span event.
  • Refactor sanitizeEventAttributes(). Now if an attribute values does not follow the requirements (defined here, the key is fully dropped.

Motivation

We want to add a recordException API in every tracers so customers can use the feature without using the OpenTelemetry one which is not consistent across tracers. Note that the function is similar to the OpenTelemetry function but is not meant to be a replica.

About the second change, while implementing the API, I found out that sanitizeEventAttributes was not complete (lacking of check for integer range for instance) and not following the RFC.
Example:
[1, [1]] is not accepted and currently the function was only removing [1].

@dubloom dubloom requested a review from a team as a code owner July 2, 2025 11:37
Copy link

github-actions bot commented Jul 2, 2025

Overall package size

Self size: 9.64 MB
Deduped: 106.63 MB
No deduping: 107.15 MB

Dependency sizes | name | version | self size | total size | |------|---------|-----------|------------| | @datadog/libdatadog | 0.7.0 | 35.02 MB | 35.02 MB | | @datadog/native-appsec | 9.0.0 | 19.6 MB | 19.61 MB | | @datadog/native-iast-taint-tracking | 4.0.0 | 11.72 MB | 11.73 MB | | @datadog/pprof | 5.9.0 | 9.77 MB | 10.14 MB | | @opentelemetry/core | 1.30.1 | 908.66 kB | 7.16 MB | | protobufjs | 7.5.3 | 2.95 MB | 5.6 MB | | @datadog/wasm-js-rewriter | 4.0.1 | 2.85 MB | 3.58 MB | | @datadog/native-metrics | 3.1.1 | 1.02 MB | 1.43 MB | | @opentelemetry/api | 1.8.0 | 1.21 MB | 1.21 MB | | import-in-the-middle | 1.14.2 | 122.36 kB | 850.93 kB | | source-map | 0.7.4 | 226 kB | 226 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | lru-cache | 7.18.3 | 133.92 kB | 133.92 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | @datadog/sketches-js | 2.1.1 | 109.9 kB | 109.9 kB | | lodash.sortby | 4.7.0 | 75.76 kB | 75.76 kB | | ignore | 5.3.2 | 53.63 kB | 53.63 kB | | istanbul-lib-coverage | 3.2.2 | 34.37 kB | 34.37 kB | | rfdc | 1.4.1 | 27.15 kB | 27.15 kB | | @isaacs/ttlcache | 1.4.1 | 25.2 kB | 25.2 kB | | dc-polyfill | 0.1.9 | 25.11 kB | 25.11 kB | | tlhunter-sorted-set | 0.1.0 | 24.94 kB | 24.94 kB | | shell-quote | 1.8.3 | 23.74 kB | 23.74 kB | | limiter | 1.1.5 | 23.17 kB | 23.17 kB | | retry | 0.13.1 | 18.85 kB | 18.85 kB | | semifies | 1.0.0 | 15.84 kB | 15.84 kB | | jest-docblock | 29.7.0 | 8.99 kB | 12.76 kB | | crypto-randomuuid | 1.0.0 | 11.18 kB | 11.18 kB | | ttl-set | 1.0.0 | 4.61 kB | 9.69 kB | | mutexify | 1.4.0 | 5.71 kB | 8.74 kB | | path-to-regexp | 0.1.12 | 6.6 kB | 6.6 kB | | koalas | 1.0.2 | 6.47 kB | 6.47 kB | | module-details-from-path | 1.0.4 | 3.96 kB | 3.96 kB |

🤖 This report was automatically generated by heaviest-objects-in-the-universe

Copy link

codecov bot commented Jul 2, 2025

Codecov Report

Attention: Patch coverage is 94.28571% with 2 lines in your changes missing coverage. Please review.

Project coverage is 79.33%. Comparing base (bc0b431) to head (2989260).
Report is 4 commits behind head on master.

Files with missing lines Patch % Lines
packages/dd-trace/src/opentracing/span.js 94.28% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #6010      +/-   ##
==========================================
- Coverage   79.53%   79.33%   -0.21%     
==========================================
  Files         477      467      -10     
  Lines       20295    20131     -164     
==========================================
- Hits        16142    15971     -171     
- Misses       4153     4160       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@pr-commenter
Copy link

pr-commenter bot commented Jul 2, 2025

Benchmarks

Benchmark execution time: 2025-07-02 12:01:58

Comparing candidate commit 2989260 in PR branch dubloom/record-exception-api with baseline commit bc0b431 in branch master.

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

Copy link
Member

@rochdev rochdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not add this to the tracer instead? This would decouple errors from spans, thus allowing us to eventually change the API so that we can record exceptions with tracing disabled.

@dubloom
Copy link
Author

dubloom commented Jul 3, 2025

@rochdev that's a valid comment. My first implementation was done in the python tracer and was decoupled from the span.

However, they asked me to do it like that in order to align with OpenTelemetry API therefore the choice has been made to follow OpenTelemetry API everywhere for consistency and for ease of use coming for an user coming from OpenTelemetry. It is released this way in Python and will be released this way in Ruby so for consistency, I'd argue it is better like that.

If at some point we are able to decouple the errors from the spans, I'd be happy to make the change and deprecate this API.

@rochdev
Copy link
Member

rochdev commented Jul 3, 2025

There is already an API to add exceptions to spans. How is this expected to interact with it? As a user, how to I differentiate between them? Do I need to use both APIs at the same time for the error to be properly reported?

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

Successfully merging this pull request may close these issues.

2 participants