fix(compose): Ensure SentryTraced spans respect ignore-by-origin requests

[0xadam-brown]

📜 Description

Fixes a bug where we set span origins for SentryTraced after their creation via the span context, resulting in our ignore-span-origins logic not being able to see them and spans being produced when they should have been ignored / suppressed.

💡 Motivation and Context

This issue has been with us for a while, but was discovered (along with a number of others) in connection with my Nav3 work.

The general rule is that we need to set span origins during creation and not afterwards via span context or else checks list ignoreSpanOrigins will be ignored.

What went wrong?

SentryTracer checks ignoredSpanOrigins during span creation, before the returned span can be mutated:

if (SpanUtils.isIgnored(scopes.getOptions().getIgnoredSpanOrigins(), spanOptions.getOrigin())) {
  return NoOpSpan.getInstance();
}

That check reads SpanOptions.origin, not the SpanContext.origin we were setting after creation.

So if a host app did this...

options.setIgnoredSpanOrigins(listOf("auto.ui.jetpack_compose"))

...it would no-op and the Compose spans were created nonetheless.

The issue affected both levels of the SentryTraced span hierarchy (ie, both parent spans and child spans).

💚 How did you test it?

Unit regression test + I had my clanker verify the fix works and is correct via our Android sample apps.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.55.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[runningcode]

This is quite a subtle bug! :O Is there a way of changing the API to make it impossible to do it the wrong way? Or throwing an exception when doing this the wrong way?

[0xadam-brown]

Rebased on an updated target + fixed minor merge conflicts; otherwise unchanged.

[0xadam-brown]

This is quite a subtle bug! :O Is there a way of changing the API to make it impossible to do it the wrong way? Or throwing an exception when doing this the wrong way?

That's indeed the question. I also ran into a similar issue w/r/t setting the start timestamp for spans in another SentryTraced PRs. I think a deep dive into our ISpan API and the constraints driving its behavior could be worthwhile at some point...