Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix environment and service name match for unary span filter expression #234

Merged
merged 1 commit into from
Aug 29, 2024

Conversation

AnandShivansh
Copy link
Contributor

Description

Please include a summary of the change, motivation and context.

Testing

Please describe the tests that you ran to verify your changes. Please summarize what did you test and what needs to be tested e.g. deployed and tested helm chart locally.

Checklist:

  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • Any dependent changes have been merged and published in downstream modules

Documentation

Make sure that you have documented corresponding changes in this repository or hypertrace docs repo if required.

@AnandShivansh AnandShivansh requested a review from a team as a code owner August 29, 2024 11:08
@AnandShivansh AnandShivansh enabled auto-merge (squash) August 29, 2024 11:09
Copy link

Test Results

127 tests  ±0   127 ✅ ±0   56s ⏱️ ±0s
 30 suites ±0     0 💤 ±0 
 30 files   ±0     0 ❌ ±0 

Results for commit ddb5285. ± Comparison against base commit 829a71c.

@AnandShivansh AnandShivansh merged commit aec20fe into main Aug 29, 2024
8 checks passed
@AnandShivansh AnandShivansh deleted the fix_environment_match branch August 29, 2024 11:11
validateNonDefaultPresenceOrThrow(
filter.getUnarySpanFilter(), UnarySpanFilterExpression.OPERATOR_FIELD_NUMBER);

final LeftOperandCase leftOperandCase = filter.getUnarySpanFilter().getLeftOperandCase();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm missing something. You're saying field must be set on 106, then immediately saying if field is set it's also an error?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry my mistake here - I saw the word FIELD and thought it was checking for the field.. field. But it's checking for the operator field.

Given this though, recommend removing this from the proto rather than relying on validation since it was just added and not yet in use.

if (spanFilter.hasRelationalSpanFilter()) {
return matchesServiceName(spanFilter.getRelationalSpanFilter(), serviceName);
} else {
if (spanFilter
.getLogicalSpanFilter()
.getOperator()
.equals(LogicalOperator.LOGICAL_OPERATOR_AND)) {
if (hasNoRelationalFilters(spanFilter.getLogicalSpanFilter())) {
return true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't necessarily hold. It seems like you're making assumptions about structure here. e.g. AND(AND(serviceName = x, otherCondition)) would stop searching as soon as it got inside the first AND.

@@ -59,6 +72,12 @@ public boolean matchesServiceName(SpanFilter spanFilter, String serviceName) {
}
}

private boolean hasNoRelationalFilters(LogicalSpanFilterExpression logicalSpanFilterExpression) {
return logicalSpanFilterExpression.getOperandsCount() == 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should recurse. Also the operand count is redundant, since if it was 0 none match would return true.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix in the later PR. This is known problem. Environment and servicename is not checked at more than 1 nested levels

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants