Transactions started with continue_trace() do not inherit sampling
#2990
Comments
|
@jwhitaker-gridcog Thank you for reporting, I am currently investigating this issue |
|
Hey @jwhitaker-gridcog! After some investigation, it looks like the problem you have run into is different and more general than transactions started with In fact, the root cause of the issue is that transactions must always be started with the In your case, this means you can work around the issue by modifying your worker function as follows: def worker(baggage_and_tp):
sentry_sdk.init(traces_sample_rate=1.0, environment="jarrad-local", debug=True)
baggage, traceparent = baggage_and_tp
try:
transaction = sentry_sdk.continue_trace(
{"baggage": baggage, "sentry-trace": traceparent}, op="task", name="child"
)
# The transaction is created with continue_trace, but we start it with start_transaction
with sentry_sdk.start_transaction(transaction):
sentry_sdk.capture_message("hi")
finally:
sentry_sdk.Hub.current.flush()I will need to discuss with the team to determine whether requiring transactions to be started via Update: I discussed with the team, and it is indeed the expected behavior that transactions only get sent to Sentry when started with |
|
Since we have determined that the behavior described here is as expected, I am closing this issue. I have opened the two issues below to improve the debug message and our docs, respectively:
Hopefully, these changes will help us to avoid confusion in the future! |
…ransaction` Users who enter a transaction without calling `start_transaction` likely intended to start the transaction, since without a call to `start_transaction`, their transaction will not get sent to Sentry. This warning message clarifies this behavior, and could help avoid the confusion that led to issue #2990.
…ransaction` Users who enter a transaction without calling `start_transaction` likely intended to start the transaction, since without a call to `start_transaction`, their transaction will not get sent to Sentry. This warning message clarifies this behavior, and could help avoid the confusion that led to issue #2990.
|
Thanks for looking into this! Can I ask what is the use case for calling continue_trace and not wanting the transaction to be sent? |
@jwhitaker-gridcog There is likely no use case for doing this. But essentially, as I understand it, the Essentially, the two functions can be summarized as follows:
|
…ransaction` Users who enter a transaction without calling `start_transaction` likely intended to start the transaction, since without a call to `start_transaction`, their transaction will not get sent to Sentry. This warning message clarifies this behavior, and could help avoid the confusion that led to issue #2990.
…ransaction` Users who enter a transaction without calling `start_transaction` likely intended to start the transaction, since without a call to `start_transaction`, their transaction will not get sent to Sentry. This warning message clarifies this behavior, and could help avoid the confusion that led to issue #2990.
|
thanks for following this up and detailed work on explanation and docs! |
…ransaction` Users who enter a transaction without calling `start_transaction` likely intended to start the transaction, since without a call to `start_transaction`, their transaction will not get sent to Sentry. This warning message clarifies this behavior, and could help avoid the confusion that led to issue #2990. Also, add tests to ensure the message is logged.
…ransaction` Users who enter a transaction without calling `start_transaction` likely intended to start the transaction, since without a call to `start_transaction`, their transaction will not get sent to Sentry. This warning message clarifies this behavior, and could help avoid the confusion that led to issue #2990. Also, add tests to ensure the message is logged.
Users who enter a transaction without calling `start_transaction` likely intended to start the transaction, since without a call to `start_transaction`, their transaction will not get sent to Sentry. This warning message clarifies this behavior, and could help avoid the confusion that led to issue #2990. Also, add tests to ensure the message is logged.
How do you use Sentry?
Sentry Saas (sentry.io)
Version
1.45.0
Steps to Reproduce
Run the following python script, setting SENTRY_DSN accordingly.
Alternatively, clone from https://github.com/jwhitaker-gridcog/sentry-bug .
Python script
Run with
demo.py main_mpordemo.py main_subp. Both demonstrate this issue in a different context.I came across this issue using multiprocessing and suspected some strangeness around
sentry_sdk.init()vsfork(), so wanted to include what I'm really doing.However I was also able to reproduce it without multiprocessing being involved at all, and I didn't want this closed as a dupe of #291 prematurely :)
Expected Result
The worker transaction should be sent to sentry, because its parent is sampled.
According to docs at https://docs.sentry.io/platforms/python/configuration/sampling/#inheritance
Actual Result
However, in logs, I can see
Full logs:
If I work around the issue with
then everything works.
It looks like
continue_trace()should be doing stuff that you are doing instart_transaction(), but instead just callsTransaction()on its own so this got forgotten?The text was updated successfully, but these errors were encountered: