Skip to content

Don't initialize Event objects when they won't be sent#1687

Merged
st0012 merged 2 commits intomasterfrom
fix-#1683
Jan 14, 2022
Merged

Don't initialize Event objects when they won't be sent#1687
st0012 merged 2 commits intomasterfrom
fix-#1683

Conversation

@st0012
Copy link
Copy Markdown
Contributor

@st0012 st0012 commented Jan 14, 2022

Fixes #1683

@st0012 st0012 added this to the 4.9.1 milestone Jan 14, 2022
@st0012 st0012 self-assigned this Jan 14, 2022
@st0012 st0012 requested a review from sl0thentr0py January 14, 2022 15:27
@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Jan 14, 2022

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.55%. Comparing base (7697af6) to head (a63511f).
⚠️ Report is 636 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1687   +/-   ##
=======================================
  Coverage   98.55%   98.55%           
=======================================
  Files         136      136           
  Lines        7691     7695    +4     
=======================================
+ Hits         7580     7584    +4     
  Misses        111      111           

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

Copy link
Copy Markdown
Member

@sl0thentr0py sl0thentr0py left a comment

Choose a reason for hiding this comment

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

hmm ideally this check should be done just once in a centralized place, but I can't see a good place for it without changing too many things, so it's fine for now :)

@st0012
Copy link
Copy Markdown
Contributor Author

st0012 commented Jan 14, 2022

@sl0thentr0py Yeah I agree with you. I think it depends on whether we expect users to initialize events themselves and call capture_event manually.

If we do, then I think the current approach (2 levels of checks) is necessary.
If we don't, we need to prohibit such usages, which should have its own PR.

@sl0thentr0py
Copy link
Copy Markdown
Member

Event.new should be considered as internal api, users shouldn't really use it directly. Only methods on hub or those exposed directly on the top-level Sentry module are our 'contract'.

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.

Sentry has RuntimeError when not enabled in current environment

3 participants