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

[BCI-3988] - FilteredLogs receive []Expression instead of whole KeyFilter #14109

Merged
merged 13 commits into from
Sep 4, 2024

Conversation

Farber98
Copy link
Contributor

@Farber98 Farber98 commented Aug 13, 2024

Task Description:

Log poller Filtered logs have no use for Key, which makes the method confusing when used outside of CR

This PR:

  • Modify FilteredLogs method so it receives []query.Expression instead of whole query.KeyFilter as param.
  • Fix references.
  • Create logpoller.Where function that doesn't receive key. It wraps query.Where

Ticket:

Note:

Merged with:

@Farber98 Farber98 self-assigned this Aug 13, 2024
@Farber98 Farber98 changed the title FilteredLogs receive []Expression instead of whole KeyFilter [BCI-3988] - FilteredLogs receive []Expression instead of whole KeyFilter Aug 13, 2024
Copy link
Contributor

@ilija42 ilija42 left a comment

Choose a reason for hiding this comment

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

Be careful with this change since this is used in other repos (although not in a lot of places), This should be either versioned or very carefully updated at the same time everywhere

@Farber98 Farber98 marked this pull request as ready for review September 2, 2024 15:53
@Farber98 Farber98 requested review from a team as code owners September 2, 2024 15:53
@Farber98 Farber98 requested review from ilija42 and removed request for a team September 2, 2024 15:53
ilija42
ilija42 previously approved these changes Sep 2, 2024
Copy link
Collaborator

@patrick-dowell patrick-dowell left a comment

Choose a reason for hiding this comment

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

What impact will this PR have on CCIP? Just want to make sure we are mindful of the concerns Makram raised. My other comments were mostly questions as I don't know much about how these expressions work.

assert.Equal(t, []query.Expression{}, result)
})

t.Run("Invalid boolean expression", func(t *testing.T) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

are the valid and invalid expressions documented somewhere? Would it make sense to go through all them in these tests and show how to properly use them?

Copy link
Contributor Author

@Farber98 Farber98 Sep 4, 2024

Choose a reason for hiding this comment

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

This logpoller.Where() function it's just a wrapper of the original one query.Where() where you don't need to provide a key param and just the expressions

The underlying function has extensive tests here which uses the test cases defined here. Also the usage eg. defined in the function comment is clear

Let me know your thoughts if this seems enough

t.Run("Valid combination of filters", func(t *testing.T) {
result, err := logpoller.Where(expr1, expr2, expr3, expr4)
assert.NoError(t, err)
assert.Equal(t, []query.Expression{expr1, expr2, expr3, expr4}, result)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I assume these filters are being combined as a logical "AND" - the events need to match all filters. What if you want a logical "OR" - events that match at least one of the filters?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was testing this function at a high level, maybe it's redundant given the underlying tests. More details in my previous comment here: #14109 (comment)

@Farber98
Copy link
Contributor Author

Farber98 commented Sep 4, 2024

@patrick-dowell

What impact will this PR have on CCIP? Just want to make sure we are mindful of the concerns Makram raised. My other comments were mostly questions as I don't know much about how these expressions work.

Mateusz commented here the following:

we keep merging chainlink repository every 2-3 weeks so if you merge that in the upstream we will get that eventually. No need to create a PR in ccip repo unless it's super critical for CCIP to have

We only need to merge core and they will eventually get these changes. We only cherry pick when changes needed are urgent as Makram said here too

Copy link
Collaborator

@patrick-dowell patrick-dowell left a comment

Choose a reason for hiding this comment

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

Cool, LGTM

@patrick-dowell patrick-dowell added this pull request to the merge queue Sep 4, 2024
Merged via the queue into develop with commit 2761cd5 Sep 4, 2024
151 checks passed
@patrick-dowell patrick-dowell deleted the BCI-3988-remove-keyfilter-from-filteredlogs branch September 4, 2024 20:38
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