Codecov Report

❌ Patch coverage is 84.61538% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.55%. Comparing base (5a122b5) to head (39e3a50).
⚠️ Report is 10 commits behind head on master.
✅ All tests successful. No failed tests found.

@@            Coverage Diff             @@
##           master    #4571      +/-   ##
==========================================
+ Coverage   84.47%   84.55%   +0.07%     
==========================================
  Files         158      158              
  Lines       16506    16535      +29     
  Branches     2865     2868       +3     
==========================================
+ Hits        13944    13981      +37     
+ Misses       1712     1706       -6     
+ Partials      850      848       -2     

Hi @Igreh, I took a quick glance at your PR – at a high level this seems reasonable; however, before I do a full review, I would appreciate if you could please add some tests for these changes, since we need tests before we can consider merging this.

Hi!
Thanks for reply. I'm not very familiar about what should be tested exactly for now (transaction was successfully started? or what objects/props must be created? and etc ) but I will take a look and try to do my best =)
If you have any advice - would be very helpful

Edit:
Or I just need to cover one missed line?

Hey @Igreh, it'd be good to have "end-to-end" (i.e., not unit tests) for the different tracing code paths. Stuff like:

• the happy path (if everything works fine, you get the transaction and it has the data you expect it to have)
• how it behaves if there's an error (a transaction still gets sent, and it has the correct status, etc.; maybe also check if the user's program still behaves as expected -- the exception bubbles up if it should bubble up, etc.)
• trace propagation (i.e., the transaction picks up propagation headers/vars if present) -- I think this might still be missing in your PR

...and/or whatever you consider important so that when the test suite is run and ends up green, you'd have a reasonable amount of confidence that tracing in the Dramatiq integration is working.

You can have a look at some of these similar integrations and their test suites (e.g. arq, huey) for inspiration.

Thanks for working on this! Let us know if you need any help.

Hi @sentrivana !
Thanks for your reply. It was very helpful.
I believe I was able to solve propagation issue (see last commit)
Also, I've changed the way dramatiq_task_id is stored - now as tag (like in celery). It's actually very convenient to find transaction by ID.
New tests were added (huey integration I used for inspiration).
One thing I can't understand for now: mechanism.type of error event is "logging" instead of "dramatiq". https://github.com/getsentry/sentry-python/pull/4571/files#diff-ed170393871d90a02937ffecacd1b736805e6ea3c43e5549fd0df9bab883709eR82
Disabling LoggingIntegration fixes it (and actually it's the way we use sentry) but I suppose the general solution must work on defaults)
Probably, I have to dig deeper to dramatiq source code to understand what's happening... Not sure but I will keep investigating

Hi @sentrivana !
Things are more complicated than I expected... =)

I'm using (and testing) my current integration on real project and
we're experiencing different side effects, but I'm curious about one thing for now:
Retried transactions must be connected by the same trace? Is any sentry agreement for such issue?
Retrying in terms of Dramatiq means requeuing message and it means baggage is propagated also. Bug or feature ? )

Failed task with 3 retries might look like this:

Hey again 👋🏻 Thanks for your time on this!

One thing I can't understand for now: mechanism.type of error event is "logging" instead of "dramatiq". https://github.com/getsentry/sentry-python/pull/4571/files#diff-ed170393871d90a02937ffecacd1b736805e6ea3c43e5549fd0df9bab883709eR82
Disabling LoggingIntegration fixes it (and actually it's the way we use sentry) but I suppose the general solution must work on defaults)

What you're seeing is likely dramatiq logging the error when it happens, and our LoggingIntegration picking it up. In case that happens, our deduplication logic (in DedupeIntegration) drops the second (in this case better) event coming directly from the integration.

What you can do is add an ignore_logger("<logger-name>") to the integration, see for example here where we were solving the same issue for strawberry-graphql. This will tell the LoggingIntegration to skip capturing events from that specific logger, so the actual events coming from the specialized integration should get through.

(I know you're not working on the error part of the integration in this PR but it's still a good improvement so feel free to include it.)

I'm using (and testing) my current integration on real project and
we're experiencing different side effects, but I'm curious about one thing for now:
Retried transactions must be connected by the same trace? Is any sentry agreement for such issue?
Retrying in terms of Dramatiq means requeuing message and it means baggage is propagated also. Bug or feature ? )

Not sure off the top of my head how this works in our other task queue integrations, but my hunch is that retries should be under one trace.

Good day everyone!
Sorry for long delay but now I'm back and going to complete this task)

Last patches are aimed to solve (I hope) all current issues:

• py36 support (ContextVar). aiocontextvars as new deps for tox.
• typing issues: incorrect import (type R was absent in earlier versions of dramatiq)
• fix test (ignore logger)

Not sure off the top of my head how this works in our other task queue integrations, but my hunch is that retries should be under one trace.

I decided to not include retries under one trace. As mentioned in commit: "Start new trace in case of retrying task. Such decision makes life easier to investigate failed transactions in complicated traces.".
As example: one transaction may include 2 or more execution of the same task. If one or more failed and dramatiq starts retrying them then trace will include huge amount of task calls. Understanding what should have happened and what actually happened becomes an extremely difficult task. The sequence of calls (at least visually) is disrupted. It's really easier to find all retries by dramatiq_message_id (which is now became tag)

Let me know if anything needs to be improved or reworked. Thanks in advance!