make span stacktrace ignore inferred spans by default#2803
Merged
jaydeluca merged 2 commits intoMay 5, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the span-stacktrace processor to skip stacktrace capture for inferred spans (which are synthesized from sampling data rather than executed on an active thread), and adds coverage to ensure this behavior.
Changes:
- Skip stacktrace capture when the span’s instrumentation scope name indicates it was produced by the inferred-spans processor.
- Extend unit tests to simulate spans with an inferred-spans instrumentation scope and assert stacktraces are not captured.
- Clean up dependencies (remove duplicate entry; add a test-only dependency used by the new test).
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
span-stacktrace/src/main/java/io/opentelemetry/contrib/stacktrace/StackTraceSpanProcessor.java |
Adds an early-return to ignore inferred spans during onEnding stacktrace capture. |
span-stacktrace/src/test/java/io/opentelemetry/contrib/stacktrace/StackTraceSpanProcessorTest.java |
Updates helpers to allow varying tracer/scope name and adds a test asserting inferred spans are ignored. |
span-stacktrace/build.gradle.kts |
Removes a duplicate dependency declaration and adds a test-only dependency for inferred-spans. |
Comment on lines
+59
to
+63
| if (!filterPredicate.test(span)) { | ||
| return; | ||
| } | ||
|
|
||
| // inferred spans are generated from sampling, thus the span processor is not actually called |
Comment on lines
+68
to
+69
| boolean isInferred = span.getInstrumentationScopeInfo().getName().equals("inferred-spans"); | ||
| if (isInferred) { |
Comment on lines
116
to
+120
| private static void checkSpanWithoutStackTrace( | ||
| Class<? extends Predicate<?>> predicateClass, | ||
| String minDurationString, | ||
| long spanDurationNanos) { | ||
| long spanDurationNanos, | ||
| String scopeName) { |
JonasKunz
approved these changes
Apr 30, 2026
Contributor
JonasKunz
left a comment
JonasKunz
left a comment
There was a problem hiding this comment.
Seems reasonable to me.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
jaydeluca
approved these changes
May 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The span stacktrace span processor captures the current thread stack trace when the span ends.
However, the inferred spans span processor produces spans that are not executed when the span is active as they are artificially generated from sampling data.
When the span stacktrace span processor is executed before the inferred spans, the inferred spans are naturally excluded, however when the stacktrace span processor is after then we have to explicitly exclude such spans. We can argue that this may be a mis-configuration in the span processor pipeline, but this creates an extra burden on user.
This is why the span stacktrace processor was created with the ability to provide a custom filter. The only known usage and filter implementation in that I'm aware of is in the Elastic (EDOT) distribution which is using the
is_inferredspan attribute to filter inferred spans.With this change:
is_inferredspan attribute to detect span attributes, we can rely on the scope name (in a sense we trade one implementation detail to another)Possible follow-up tasks
is_inferredspan attribute in inferred spans: it is not part of semconv and should not be used by anyone after this change is effectivefilteroption in span stacktrace span processor.