Skip to content

Lazily evaluate ExceptionEventData exception.* attributes #7172

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: main
Choose a base branch
from

Conversation

jack-berg
Copy link
Member

Currently, we compute exception.* span event attributes immediately when recordException is called.

With this PR, those attributes are computed lazily at the time of export. This should shift CPU / memory from hot path to export background threads.

@jack-berg jack-berg requested a review from a team as a code owner March 4, 2025 22:41

abstract SpanLimits getSpanLimits();

public abstract Attributes getAdditionalAttributes();
Copy link
Member Author

Choose a reason for hiding this comment

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

cc @HaloFour I believe this should be a (temporary) workaround to the changes in #6795. To restore the behavior you were relying on, you should be able to:

  • Check if eventData instanceOf LazyExceptionEventData
  • If so, access the attributes via LazyExceptionEventData#getAdditionalAttributes() without rendering the exception.*

I'd like to followup with this PRs change with:

  • Add SDK customization hook for defining your own exception rendering logic
  • Introduce API for setting exception on logs LogRecordBuilder#setException
  • Improve the default exception rendering logic to be attribute limits aware, so that if attributes can't be longer than 1000 characters we don't waste resources rendering the stacktrace past this limit

Copy link

codecov bot commented Mar 4, 2025

Codecov Report

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

Project coverage is 89.94%. Comparing base (9cb6365) to head (081960d).

Files with missing lines Patch % Lines
...dk/trace/internal/data/LazyExceptionEventData.java 93.93% 0 Missing and 2 partials ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main    #7172      +/-   ##
============================================
+ Coverage     89.92%   89.94%   +0.01%     
- Complexity     6721     6728       +7     
============================================
  Files           765      766       +1     
  Lines         20277    20305      +28     
  Branches       1985     1988       +3     
============================================
+ Hits          18234    18263      +29     
- Misses         1448     1449       +1     
+ Partials        595      593       -2     

☔ 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.

@trask
Copy link
Member

trask commented Apr 10, 2025

is there a connection or overlap between this PR and #7182?

@jack-berg
Copy link
Member Author

is there a connection or overlap between this PR and #7182?

They solve separate problems but there will be merge conflicts I'll need to resolve regardless of which is merged first

@trask
Copy link
Member

trask commented Apr 10, 2025

Sounds good I'll review this one second

@jack-berg
Copy link
Member Author

Sounds good I'll review this one second

Should be good to go now that #7182 is merged

// - exception.type
// - exception.message
// - exception.stacktrace
return getAdditionalAttributes().size() + 3;
Copy link
Member

Choose a reason for hiding this comment

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

for users of this method does it matter that there could be overlap and so this calculation could overcount (e.g. a user overriding exception.message)?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh great point. Need to think this through a little more

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

Successfully merging this pull request may close these issues.

2 participants