use key presence for stacktrace filter instead of value - #400
Conversation
There was a problem hiding this comment.
Pull request overview
This PR changes the SpanStacktraceFilter to check for attribute key presence instead of checking for string-typed attribute values. This makes the filter type-agnostic and aligns with the documented behavior.
Key changes:
- Modified filter logic to check if attribute keys exist regardless of their value types
- Changed
filterAttributesfrom static to instance field to support proper testing - Enhanced test coverage with multiple attribute types (string, long, string arrays, long arrays)
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
SpanStacktraceFilter.java |
Refactored the test method to check for attribute key presence instead of string attribute values, and changed filterAttributes from static to instance field |
SpanStacktraceFilterTest.java |
Replaced mock-based tests with comprehensive tests covering multiple attribute types and proper setup/teardown |
|
|
||
| public class SpanStacktraceFilter implements Predicate<ReadableSpan> { | ||
| private static final Set<String> filterAttributes = new HashSet<>(); | ||
| private final Set<String> filterAttributes = new HashSet<>(); |
There was a problem hiding this comment.
Changing filterAttributes from static to instance field may cause thread safety issues if SpanStacktraceFilter instances are shared across threads. Each call to test() modifies this field. Consider making this field static and using thread-safe operations, or document that instances should not be shared across threads.
| Set<String> attributes = | ||
| readableSpan.getAttributes().asMap().keySet().stream() | ||
| .map(AttributeKey::getKey) | ||
| .collect(Collectors.toSet()); | ||
| attributes.retainAll(filterAttributes); | ||
| return !attributes.isEmpty(); |
There was a problem hiding this comment.
This implementation creates a new Set and copies all attribute keys on every invocation. For spans with many attributes, this could be inefficient. Consider using a stream-based approach that short-circuits on the first match: filterAttributes.stream().anyMatch(attr -> readableSpan.getAttributes().asMap().keySet().stream().anyMatch(key -> key.getKey().equals(attr)))
| Set<String> attributes = | |
| readableSpan.getAttributes().asMap().keySet().stream() | |
| .map(AttributeKey::getKey) | |
| .collect(Collectors.toSet()); | |
| attributes.retainAll(filterAttributes); | |
| return !attributes.isEmpty(); | |
| return filterAttributes.stream().anyMatch( | |
| attr -> readableSpan.getAttributes().asMap().keySet().stream() | |
| .anyMatch(key -> key.getKey().equals(attr)) | |
| ); |
There was a problem hiding this comment.
Any merit to this suggestion?
There was a problem hiding this comment.
yeah. compute-wise superior and memory-wise inferior in worst case scenario. all round superior actually.
06cb240 to
dadb570
Compare
dadb570 to
e099da2
Compare
| Set<String> attributes = | ||
| readableSpan.getAttributes().asMap().keySet().stream() | ||
| .map(AttributeKey::getKey) | ||
| .collect(Collectors.toSet()); | ||
| attributes.retainAll(filterAttributes); | ||
| return !attributes.isEmpty(); |
There was a problem hiding this comment.
Any merit to this suggestion?
a8dcd6e to
6609814
Compare
6609814 to
317dddf
Compare
|
merged because lambda-release-test failing is not actual test failure. it's failure to write test results file. |
Context:
Span stacktrace filternow checks key presence instead of limiting to only string-key values. This type agnostic approach is consistent with current documentation.Test Plan:
New unit test and regression.
Test services data