fix(otel): only set Scope.Transaction in SentrySpanProcessor when null by tsushanth · Pull Request #5337 · getsentry/sentry-dotnet

tsushanth · 2026-07-03T01:03:56Z

Problem

SentrySpanProcessor.OnStart calls ConfigureScope unconditionally:

_hub.ConfigureScope(static (scope, transaction) => scope.Transaction = transaction, transaction);

When two root OTel activities overlap and neither is a child of the other, this silently overwrites whatever transaction was already on the scope with the new one. As the issue notes, the intuitive default is to not overwrite an existing transaction.

Fix

Add a null-check guard inside the ConfigureScope lambda:

_hub.ConfigureScope(static (scope, transaction) =>
{
    if (scope.Transaction is null)
    {
        scope.Transaction = transaction;
    }
}, transaction);

Scope.Transaction is only set when it is currently null; an already-present transaction is left unchanged.

Test

Added OnStart_WithExistingTransactionOnScope_DoesNotOverwriteExistingTransaction to SentrySpanProcessorTests: sets a transaction on the scope, starts a new root activity, calls OnStart, and asserts the scope still holds the original transaction.

This is intentionally not bundled with #2399 (the AutoSetScopeTransactions opt-in), per the issue's notes.

When two root OTel activities overlap and neither is a child of the other, OnStart was calling ConfigureScope unconditionally with scope.Transaction = transaction, silently overwriting whatever transaction was already on the scope. The more intuitive default is to not overwrite an existing transaction. Add a null-check guard to ConfigureScope so Scope.Transaction is only set when it is currently null. Fixes getsentry#5314

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a3f87c. Configure here.}

cursor · 2026-07-03T01:04:43Z

+        ITransaction? scopeTransaction = null;
+        _fixture.Hub.ConfigureScope(scope => scopeTransaction = scope.Transaction);
+        scopeTransaction.Should().BeSameAs(existing, "OnStart should not overwrite an existing Scope.Transaction");
+    }


Test skips CreateRootSpan path

Medium Severity

OnStart_WithExistingTransactionOnScope_DoesNotOverwriteExistingTransaction seeds the scope with a Sentry-instrumented transaction, so OnStart infers a non-OTel parent and calls CreateChildSpan instead of CreateRootSpan. The new null guard on scope.Transaction never runs, so the test would still pass if that guard were removed and does not cover overlapping OTel root activities from GH-5314.

^{Reviewed by Cursor Bugbot for commit 8a3f87c. Configure here.}

sentry · 2026-07-03T01:06:19Z

+        _hub.ConfigureScope(static (scope, transaction) =>
+        {
+            if (scope.Transaction is null)
+            {
+                scope.Transaction = transaction;
+            }
+        }, transaction);


Bug: When multiple root activities overlap, if the first one finishes, a new activity can take over the scope's transaction, leaving a longer-running, pre-existing activity untracked on the scope.
_{Severity: LOW}

Suggested Fix

The logic in scope.ResetTransaction should be enhanced. Instead of unconditionally setting the transaction to null when the current one finishes, it should check for other active transactions that could take ownership of the scope. This would prevent a new, unrelated transaction from claiming the scope while another is still active, maintaining a more consistent state.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: src/Sentry.OpenTelemetry/SentrySpanProcessor.cs#L179-L185 Potential issue: A state inconsistency can occur with multiple overlapping root OpenTelemetry activities. The new logic only sets `scope.Transaction` if it's `null`. If the first root activity (A) finishes, it calls `scope.ResetTransaction(A)`, which nullifies the transaction on the scope. If a second root activity (B) started while A was active, it would not have been set on the scope. If a third root activity (C) starts after A finishes, it will find `scope.Transaction` is `null` and set itself as the current transaction. This leads to a situation where activity B is still running, but the scope incorrectly points to activity C, creating a logical inconsistency in which transaction is considered 'current'. While this doesn't cause data loss or crashes, it violates the principle that the scope should track the active transaction.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

Flash0ver · 2026-07-03T14:16:36Z

+        sut.OnStart(data!);
+
+        // Assert - the pre-existing transaction must still be on the scope
+        ITransaction? scopeTransaction = null;


issue: test was neither run nor built

there is no ITransaction type

this project does not have Nullable Reference Types enabled

Flash0ver · 2026-07-03T14:18:29Z

+    [Fact]
+    public void OnStart_WithExistingTransactionOnScope_DoesNotOverwriteExistingTransaction()


issue: test is ineffective

Currently, this test does not actually cover the modification, and does not cover the modified method SentrySpanProcessor.CreateRootSpan.

@jamescrosswell I wonder if Mutation Testing could cover such issues early ... e.g. if we only run mutation tests on the changes per PR, and only via the test cases that cover the /src/ changes of the PR.

Flash0ver · 2026-07-03T14:23:10Z

+        // Arrange - simulate a root OTel activity starting while another transaction is
+        // already on the scope (e.g. two overlapping root activities). The processor should
+        // not overwrite the existing transaction (see GH-5314).


thought: comments don't add additional value

IMO, the comments in this test apart from Arrange/Assert/Assert don't really add any additional value:

Assert: the existing transaction is called "Existing"

Act: the New Root Activity that is started is called "NewRootActivity"

also: actually, Act is missing for the Act portion of the test

Assert: the because string parameter to the assertion describes

To me, the combination of Test-Name + Test-Logic + String-Parameters already describe what this test is covering and asserting.

Flash0ver · 2026-07-03T14:26:44Z

+        // Only set Scope.Transaction when it is currently null. Overwriting an existing
+        // transaction (which can happen when two root OTel activities overlap and neither is
+        // a child of the other) silently drops the previous transaction's scope context.
+        // See https://github.com/getsentry/sentry-dotnet/issues/5314


suggestion: shorten comment

Although this comment does add value ... I find it a bit lengthy.
Perhaps we can shorten it a bit: for example: Only set Scope.Transaction when it is currently null is just describing the C# syntax in use.

Flash0ver · 2026-07-03T14:32:08Z

+        // Only set Scope.Transaction when it is currently null. Overwriting an existing
+        // transaction (which can happen when two root OTel activities overlap and neither is
+        // a child of the other) silently drops the previous transaction's scope context.
+        // See https://github.com/getsentry/sentry-dotnet/issues/5314


question: do we want to add links to issues more aggressively? @jamescrosswell

Previously, we only added links to the respective GitHub issue, when the code isn't too obvious what it's trying to achieve in a rather complex flow ... or when the solution in place should be reviewed/revisited at some point in time when it is a workaround.

But it seems that Coding Agents like to add both a summary from the GitHub issue, as well as a link to the GitHub issue, and additionally describe the code semantics ahead.

In this case, I would prefer to either have a one-liner, or two/three words + link to the GitHub issue ... but both - to me - is a bit lengthy. To be fair, I might exaggerate "the problem" here a bit. What do you think?

Flash0ver · 2026-07-03T14:36:37Z

Thank you very much, @tsushanth, for your contribution to the Sentry .NET SDK!
I left some comments about the test-case, and commented on the comments 😉

tsushanth requested review from Flash0ver and jamescrosswell as code owners July 3, 2026 01:03

github-actions Bot added the risk: low PR risk score: low label Jul 3, 2026

cursor Bot reviewed Jul 3, 2026

View reviewed changes

sentry Bot reviewed Jul 3, 2026

View reviewed changes

Flash0ver requested changes Jul 3, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(otel): only set Scope.Transaction in SentrySpanProcessor when null#5337

fix(otel): only set Scope.Transaction in SentrySpanProcessor when null#5337
tsushanth wants to merge 1 commit into
getsentry:mainfrom
tsushanth:fix/span-processor-overwrite-transaction

tsushanth commented Jul 3, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

cursor Bot Jul 3, 2026

Uh oh!

sentry Bot Jul 3, 2026

Uh oh!

Flash0ver Jul 3, 2026 •

edited

Loading

Uh oh!

Flash0ver Jul 3, 2026 •

edited

Loading

Uh oh!

Flash0ver Jul 3, 2026

Uh oh!

Flash0ver Jul 3, 2026

Uh oh!

Flash0ver Jul 3, 2026

Uh oh!

Flash0ver Jul 3, 2026

Uh oh!

Flash0ver commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		[Fact]
		public void OnStart_WithExistingTransactionOnScope_DoesNotOverwriteExistingTransaction()

Uh oh!

Uh oh!

Conversation

tsushanth commented Jul 3, 2026

Problem

Fix

Test

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

cursor Bot Jul 3, 2026

Choose a reason for hiding this comment

Test skips CreateRootSpan path

Uh oh!

sentry Bot Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

Flash0ver Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Flash0ver Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Flash0ver Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

Flash0ver Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

Flash0ver Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

Flash0ver Jul 3, 2026

Choose a reason for hiding this comment

Uh oh!

Flash0ver commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Flash0ver Jul 3, 2026 •

edited

Loading

Flash0ver Jul 3, 2026 •

edited

Loading