Skip to content

fix(integrations): asyncio: continuation trace transactions #5526

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.

Sign up for GitHub

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

Draft
constantinius wants to merge 1 commit into
base: master
Choose a base branch
from
+15 −9
Draft

fix(integrations): asyncio: continuation trace transactions #5526

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 15 additions & 9 deletions sentry_sdk/integrations/asyncio.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,12 @@
coro: "Coroutine[Any, Any, Any]",
**kwargs: "Any",
) -> "asyncio.Future[Any]":
# we get the current span here, as later it may already be closed
in_span = sentry_sdk.get_current_span() is not None
Copy link
Contributor Author

@constantinius constantinius Feb 24, 2026

Choose a reason for hiding this comment

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

We have to get the info whether we are in a transaction straight away before it closes.

headers = dict(
sentry_sdk.get_current_scope().iter_trace_propagation_headers()
)

@_wrap_coroutine(coro)
async def _task_with_sentry_span_creation() -> "Any":
result = None
Expand All @@ -66,16 +72,16 @@
)
task_spans = integration.task_spans if integration else False

if task_spans and in_span:

Check warning on line 75 in sentry_sdk/integrations/asyncio.py

View workflow job for this annotation

GitHub Actions / warden: find-bugs

Changed conditional skips span creation when task_spans=True but no active span exists 

The condition changed from `if task_spans` to `if task_spans and in_span`. This means when `task_spans=True` but there's no current active span (`in_span=False`), no transaction/span will be created at all. Previously, a span would still be created in this case. This is a behavioral change that could result in missing traces for orphaned async tasks.
Copy link
Contributor

@github-actions github-actions bot Feb 24, 2026

Choose a reason for hiding this comment

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

Changed conditional skips span creation when task_spans=True but no active span exists

The condition changed from if task_spans to if task_spans and in_span. This means when task_spans=True but there's no current active span (in_span=False), no transaction/span will be created at all. Previously, a span would still be created in this case. This is a behavioral change that could result in missing traces for orphaned async tasks.

Verification

Compared the original condition if task_spans (line ~64 in context) with new condition if task_spans and in_span at line 75. When in_span is False but task_spans is True, the new code enters the else branch and uses nullcontext(), creating nothing.

Identified by Warden find-bugs · DA3-SV4

Copy link
Contributor Author

@constantinius constantinius Feb 24, 2026

Choose a reason for hiding this comment

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

We should probably add a new option if we want to go that route

transaction = sentry_sdk.continue_trace(
headers, op="task", name="downstream"

Check failure on line 77 in sentry_sdk/integrations/asyncio.py

View workflow job for this annotation

GitHub Actions / warden: find-bugs

Hardcoded transaction name 'downstream' loses coroutine-specific tracing context 

The new code uses a hardcoded `name="downstream"` instead of `name=get_name(coro)` which previously captured the actual coroutine function name (e.g., 'foo', 'bar'). This eliminates meaningful trace identification - all async tasks will now appear as 'downstream' rather than their actual function names, making debugging and performance analysis significantly harder.
Copy link
Contributor

@github-actions github-actions bot Feb 24, 2026

Choose a reason for hiding this comment

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

Hardcoded transaction name 'downstream' loses coroutine-specific tracing context

The new code uses a hardcoded name="downstream" instead of name=get_name(coro) which previously captured the actual coroutine function name (e.g., 'foo', 'bar'). This eliminates meaningful trace identification - all async tasks will now appear as 'downstream' rather than their actual function names, making debugging and performance analysis significantly harder.

Verification

Read the full asyncio.py file and compared the diff. The original code at line ~65 used name=get_name(coro) to capture the coroutine name. The new code at line 77 hardcodes name="downstream". Tests in test_asyncio.py (lines 94, 101) expect transaction_event["spans"][1]["description"] == "foo" which will fail with this change.

Suggested fix: Pass the coroutine name to continue_trace and start_transaction

Suggested change
headers, op="task", name="downstream"
coro_name = get_name(coro)
headers, op=OP.FUNCTION, name=coro_name, origin=AsyncioIntegration.origin

Identified by Warden find-bugs · MFT-ANR

)

Check warning on line 78 in sentry_sdk/integrations/asyncio.py

View workflow job for this annotation

GitHub Actions / warden: find-bugs

Origin attribute not set on new transactions, breaking trace origin tracking 

The original code set `origin=AsyncioIntegration.origin` (which equals 'auto.function.asyncio') on spans. The new transaction creation doesn't pass an origin, so it will default to 'manual'. This breaks the test at test_asyncio.py:395 which expects `event["spans"][0]["origin"] == "auto.function.asyncio"` and loses the ability to identify spans created by the asyncio integration.
Comment on lines +76 to +78
Copy link
Contributor

@github-actions github-actions bot Feb 24, 2026

Choose a reason for hiding this comment

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

Origin attribute not set on new transactions, breaking trace origin tracking

The original code set origin=AsyncioIntegration.origin (which equals 'auto.function.asyncio') on spans. The new transaction creation doesn't pass an origin, so it will default to 'manual'. This breaks the test at test_asyncio.py:395 which expects event["spans"][0]["origin"] == "auto.function.asyncio" and loses the ability to identify spans created by the asyncio integration.

Verification

Compared the diff showing removal of origin=AsyncioIntegration.origin. Verified that continue_trace in scope.py doesn't propagate origin to child spans. Test at test_asyncio.py line 395 checks for 'auto.function.asyncio' origin.

Identified by Warden find-bugs · TZS-6DB

ctx = sentry_sdk.start_transaction(transaction)
else:
ctx = nullcontext()

with sentry_sdk.isolation_scope():
with (
sentry_sdk.start_span(
op=OP.FUNCTION,
name=get_name(coro),
origin=AsyncioIntegration.origin,
)
if task_spans
else nullcontext()
):
with ctx:
try:
result = await coro
except StopAsyncIteration as e:
Expand Down
Loading