chore: add tag type filter support in attribute keys

[srikanthccv]

Summary

This helps when we want to show only resource attributes in the suggestions.

---

Important

Add support for filtering attribute keys by tag type in GetLogAttributeKeys and GetTraceAttributeKeys, with request parsing and validation updates.

• Behavior:
  • Add tagType filter to GetLogAttributeKeys and GetTraceAttributeKeys in reader.go to filter attribute keys by tag type.
  • Modify query construction to include tagType conditionally based on request in reader.go.
  • Update parseFilterAttributeKeyRequest in parser.go to parse tagType from request and validate it.
• Models:
  • Add TagType field to FilterAttributeKeyRequest in v3.go.
  • Implement Validate() for TagType in v3.go.
• Tests:
  • Add test cases for tagType in TestParseFilterAttributeKeyRequest in parser_test.go.

^{This description was created by for 6d24d38. It will automatically update as commits are pushed.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 6d24d38 in 2 minutes and 23 seconds

More details

• Looked at 182 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 15 drafted comments based on config settings.

1. pkg/query-service/model/v3/v3.go:229

• Draft comment:
  New TagType definition and constants added. Consider adding comments to clarify that an empty value is interpreted as 'retrieve all attributes' for backward compatibility.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. pkg/query-service/model/v3/v3.go:237

• Draft comment:
  The Validate() method for TagType currently treats an empty string as invalid. Ensure this is intentional since parser logic treats an empty tag type as valid (for retrieving all attributes).
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

3. pkg/query-service/model/v3/v3.go:247

• Draft comment:
  In FilterAttributeKeyRequest, the new TagType field is added. Consider documenting its intended behavior (especially the significance of empty string) to guide future users.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. pkg/query-service/app/parser.go:722

• Draft comment:
  The inline comment about tagType validation (e.g. 'what is happening here?') is ambiguous. Consider clarifying or removing it, and document that an invalid tagType is silently defaulted to an empty string for backward compatibility.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The existing inline comments actually provide useful context about why the code behaves this way (backward compatibility). The comment "what is happening here?" is a bit informal but the explanation that follows is clear and valuable. Removing these comments would make the code harder to understand.
  The PR comment could be right that "what is happening here?" is too informal. And maybe the comments could be more concise.
  While the style could be improved, the substance of the inline comments is valuable for explaining the backward compatibility decision. Removing them entirely would hurt code maintainability.
  The PR comment should be rejected. The existing inline comments provide important context about backward compatibility that should be preserved.

5. pkg/query-service/app/parser_test.go:172

• Draft comment:
  Test cases now cover the new tagType parameter. Consider adding tests for edge cases like input with leading/trailing whitespace to ensure proper handling.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

6. pkg/query-service/model/v3/v3.go:237

• Draft comment:
  The TagType.Validate() method only accepts the three valid constants, so an empty string will be considered invalid. If empty is meant to denote 'all' or unspecified, consider allowing it as a valid value or document the behavior clearly.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

7. pkg/query-service/model/v3/v3.go:308

• Draft comment:
  The new TagType field in FilterAttributeValueRequest is not validated in its Validate() method. Consider adding a validation check (e.g., if non-empty, call TagType.Validate()) to ensure consistency.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

8. pkg/query-service/app/clickhouseReader/reader.go:4157

• Draft comment:
  Typo: The variable name 'atrributeValue' is misspelled. Please correct it to 'attributeValue'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

9. pkg/query-service/app/clickhouseReader/reader.go:5311

• Draft comment:
  Typo: The type name 'ReleStateItem' appears to be misspelled. If this is meant to represent a rule state item, consider renaming it to 'RuleStateItem' for clarity and consistency.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

10. pkg/query-service/app/clickhouseReader/reader.go:3040

• Draft comment:
  Typographical error in SQL string formatting: In the UpdateLogField function, the column name for the existence column and the index name are not properly enclosed in backticks (e.g. should be formatted as %s_exists with both starting and ending backticks). Please adjust the formatting to consistently enclose the identifiers in backticks.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

11. pkg/query-service/app/parser.go:727

• Draft comment:
  In the comment on line 728, consider adding proper punctuation and spacing. For example, instead of 'if tagType is undefined(uh oh javascript)', it could be 'if tagType is undefined (uh oh, JavaScript)'. This improves readability but doesn't affect functionality.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
  The comment is about a purely cosmetic change to comment formatting. It doesn't affect functionality or code quality in any meaningful way. According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. Comment formatting falls into this category.
  Perhaps clear and well-formatted comments are important for code readability and maintenance? Maybe poor comment formatting could confuse future developers?
  While good comment formatting is nice to have, this kind of minor stylistic feedback doesn't meet the bar for a PR comment. It's too trivial and doesn't impact code quality or functionality.
  Delete this comment as it's purely about comment formatting and doesn't meet the threshold for importance in PR comments.

12. pkg/query-service/app/parser.go:725

• Draft comment:
  Consider updating 'i.e retrieve all attributes' to 'i.e., retrieve all attributes' for improved clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The comment is about a very minor punctuation issue in a code comment. It doesn't affect functionality, readability, or maintainability in any meaningful way. The rules state not to make comments that are obvious or unimportant, and this seems to fall into that category.
  Could proper punctuation in comments help with documentation clarity and professionalism? Is there value in maintaining consistent style in comments?
  While consistent style is good, this level of nitpicking about punctuation in comments doesn't provide enough value to justify a PR comment. The meaning is perfectly clear either way.
  Delete this comment as it's too minor and doesn't meaningfully improve the code.

13. pkg/query-service/app/parser_test.go:18

• Draft comment:
  Typo: The test function 'TestParseAggregateAttrReques' appears to be missing a 't' at the end. Consider renaming it to 'TestParseAggregateAttrRequest' for clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

14. pkg/query-service/app/parser_test.go:1440

• Draft comment:
  Typo: The test case description 'Unknow variable in expression' should be corrected to 'Unknown variable in expression'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

15. pkg/query-service/model/v3/v3.go:1356

• Draft comment:
  Typo: 'priortize' should be corrected to 'prioritize'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_bk7rhZQHOpxL8VgR

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.