feat: add automatic reporting of handled errors#4604
Conversation
|
Thank you for updating Change log entry section 👏 Visited at: 2025-05-14 18:18:28 UTC |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4604 +/- ##
==========================================
- Coverage 97.76% 97.72% -0.04%
==========================================
Files 1422 1441 +19
Lines 86719 87195 +476
Branches 4405 4469 +64
==========================================
+ Hits 84783 85214 +431
- Misses 1936 1981 +45 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Datadog ReportBranch report: ✅ 0 Failed, 21293 Passed, 1373 Skipped, 3m 45.52s Total Time |
BenchmarksBenchmark execution time: 2025-05-16 11:24:33 Comparing candidate commit 2e52462 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 31 metrics, 2 unstable metrics. |
493c7ee to
6fb24d9
Compare
p-datadog
left a comment
p-datadog
left a comment
There was a problem hiding this comment.
I think error tracking needs to be a top-level module (moved out of core). Core means functionality used by products, and my understanding is error tracking is a product.
marcotc
left a comment
marcotc
left a comment
There was a problem hiding this comment.
Because we are adding a global TracePoint, thus adding overhead to the user application that is proportional to the user code, no Datadog code, we should add some benchmarks to ensure our solution is performant.
You can see examples in the benchmarks directory, like: https://github.com/DataDog/dd-trace-rb/blob/master/benchmarks/tracing_trace.rb
You probably want to create a new file, then add it here: https://github.com/DataDog/dd-trace-rb/blob/master/benchmarks/run_all.sh
f8acde4 to
7968375
Compare
Datadog Summary❌ Code Quality ❌ Code Security ✅ Dependencies Was this helpful? Give us feedback! |
6f51515 to
3804a7b
Compare
marcotc
left a comment
marcotc
left a comment
There was a problem hiding this comment.
Awesome work, I just left a few documentation suggestions!
Strech
left a comment
Strech
left a comment
There was a problem hiding this comment.
I think we can slightly simplify and Ruby-fy this code
Strech
left a comment
Strech
left a comment
There was a problem hiding this comment.
I'm fine with that changes 👍🏼
But I would like to demand the Rubocop to be enabled. First of all, I've pointed out lots of small issue which suppose to be eliminated by Rubocop. At the same time many similar issues are still present.
I'm not sure what leads to the disablement of the Rubocop, but I don't see any objective reason
Co-authored-by: Sergey Fedorov <[email protected]>
I believe this PR is using standard, not rubocop. This is the default for any new folders -- you either opt out of standard or opt out of rubocop. |
Strech
left a comment
Strech
left a comment
There was a problem hiding this comment.
I'm approving this PR, but IMHO too many minor here-and-there corrections are not catched by standard-rb.
9 participants
What does this PR do?
The PR adds the automatic reporting of handled errors. Whenever an error is handled, it will be attached (if not re-thrown) as a span event to a
span_operation. By adding a specific tag to the span as well, Error Tracking will be able to fingerprint the span event to report the errors in its product.Brief specification can be found on this link
Motivation:
Error Tracking released Error Tracking Standalone. This allows a user to get all the errors without using tracing. Error Tracking wants a user to be able to get handled and unhandled errors on Error Tracking without any manual instrumentation
Change log entry
Yes. ErrorTracking: Add automatic reporting of handled errors.
How to test the change?
spec/error_tracking/component_spec.rb