Let Transaction constructor take an optional hub argument#1384
Let Transaction constructor take an optional hub argument#1384
Conversation
st0012
commented
Apr 5, 2021
- This makes the SDK matches sentry-python's implementation.
- Having a hub inside a Span/Transaction may be necessary for future features.
- This eliminates the optional configuration arguments in different places, which makes it easier to understand and refactor.
Codecov Report
@@ Coverage Diff @@
## master #1384 +/- ##
==========================================
- Coverage 98.09% 95.00% -3.10%
==========================================
Files 208 98 -110
Lines 9223 4681 -4542
==========================================
- Hits 9047 4447 -4600
- Misses 176 234 +58
Continue to review full report at Codecov.
|
a5c9950 to
9d4345c
Compare
rhcarvalho
left a comment
There was a problem hiding this comment.
Good change 👍
I have one suggestion to simplify the relationship between transactions and hub (and spans should not know about hub).
29d3432 to
1ed7c71
Compare
1ed7c71 to
d0f76d7
Compare
| @@ -108,6 +111,8 @@ def set_initial_sample_decision(sampling_context:, configuration: Sentry.configu | |||
| end | |||
|
|
|||
| def finish(hub: nil) | |||
There was a problem hiding this comment.
I think callers should never pass a different hub here than the one used to start the transaction, but I'm okay if it is not removed from the API (I'm aware Python has it for historical reasons, committed 2 years ago...)
1. This makes the SDK matches sentry-python's implementation. 2. Having a hub inside a Transaction may be necessary for future features. 3. This eliminates the optional configuration arguments in different places, which makes it easier to understand and refactor.
d0f76d7 to
259b329
Compare