Drop spans for child-to-parent ordered traces in SpanFilter #2074
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.
Addresses #2038
Problem
SpanFilter
attempts to drop all descendant spans for any span targeted by the filter. To do this efficiently, it depends upon the spans to be ordered in a particular way in the trace span array: parent-to-child.In 1.x, this ordering reversed, thereby breaking the filter.
Solution
As a partial solution, this PR simply reverse iterates the span array, applying the same logic. This should address most of the old behavior, however, it is still an incomplete solution, since it is still order dependent, just the opposite now. Furthermore, it's actually impossible for
SpanFilter
to work effectively if a trace is ever flushed in smaller segments, as is often the case in partial flushing.In short, this a workaround to try to restore previous 0.x behavior in most cases. It needs further work to fully address.