-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
refactor: use conditions filter #4195
refactor: use conditions filter #4195
Conversation
NV-2868 deprecated the use of MessageMatcher use-case, and switch to ConditionsFilter use-case
What?deprecated the use of MessageMatcher usecase and switch to ConditionsFilter usecase Why? (Context)In the past we used MessageMatcher in the IMO there is no reason to have them both. Definition of Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now we have the execution detail of the filter action.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On create workflow we use Partial where we have IMessageFilter with optional isNegated
and type
therefore I aligned those types to be optional as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
refactored to use Conflict Filter use case, we still need to change this spec name and delete the MessageMatcher use-case.
This spec will remain in the worker project because we still do not run the application generic tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as on the comment above:
On create workflow we use Partial where we have IMessageFilter with optional isNegated
and type
therefore I aligned those types to be optional as well.
export class ConditionsFilterCommand extends EnvironmentWithUserCommand { | ||
@IsDefined() | ||
filters: StepFilter[]; | ||
|
||
job?: IJob; | ||
|
||
step?: INotificationTemplateStep; | ||
|
||
variables?: IFilterVariables; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We allow the passing of the data if exists. if not, we will fetch it in the use case if needed.
const filters = command.filters?.length | ||
? command.filters | ||
: command.step?.filters?.length | ||
? command.step.filters | ||
: []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not all of the clients have the job entity with filters (like select integrations), therefore we allow passing filters separately with priority.
@@ -214,9 +244,8 @@ export class ConditionsFilter extends Filter { | |||
command: ConditionsFilterCommand, | |||
filterProcessingDetails: FilterProcessingDetails | |||
): Promise<boolean> { | |||
const subscriber = await this.subscriberRepository.findOne({ | |||
_id: command.job.subscriberId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this one is a bug, because Subscriber._id is not equal to job.subscriberId.
}; | ||
} | ||
|
||
public static sumFilters( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copied from message matcher for our use.
const { webhookFilters, otherFilters } = this.splitFilters(filter); | ||
|
||
const matchedOtherFilters = await this.filterAsync(otherFilters, (i) => | ||
this.processFilter(variables, i, command, filterProcessingDetails) | ||
); | ||
if (otherFilters.length !== matchedOtherFilters.length) { | ||
return false; | ||
} | ||
|
||
const matchedWebhookFilters = await this.filterAsync(webhookFilters, (i) => | ||
this.processFilter(variables, i, command, filterProcessingDetails) | ||
); | ||
|
||
return matchedWebhookFilters.length === webhookFilters.length; | ||
} | ||
|
||
return filter.children.length === matchedOtherFilters.length; | ||
private splitFilters(filter: StepFilter) { | ||
const webhookFilters = filter.children.filter( | ||
(childFilter) => childFilter.on === 'webhook' | ||
); | ||
|
||
const otherFilters = filter.children.filter( | ||
(childFilter) => childFilter.on !== 'webhook' | ||
); | ||
|
||
return { webhookFilters, otherFilters }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was missing from the message matcher usecase
} | ||
|
||
@Instrument() | ||
private async normalizeVariablesData(command: ConditionsFilterCommand) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here we fetch the variable is they are needed and missing from the command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
refactor to use the updated command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
refactor to use the updated command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was not sure how to call this folder 😅
if (singleRule) { | ||
const result = await this.processFilter(variables, children[0], command, filterProcessingDetails); | ||
if (!prefiltering) { | ||
await this.createExecutionDetails.execute( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can not find this detail somewhere in the new code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you referring to the createExecutionDetails execution or if (singleRule)
block?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to the createExecutionDetails
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we will still log the execution detail in send-message.usecase.ts
if shouldRun.passed is false, and we won't print in queue-next-job.usecase.ts the same as it was before because of the flag. or did u miss something?
for the moment i remove the responsibility of the createExecutionDetails execution from the filter, do you think we should return it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the one of this type is not used anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understood what you mean here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davidsoderberg i will merge this one for now, please let me know if i missed something here 🙏
packages/application-generic/src/usecases/conditions-filter/conditions-filter.usecase.ts
Outdated
Show resolved
Hide resolved
packages/application-generic/src/usecases/conditions-filter/conditions-filter.usecase.ts
Outdated
Show resolved
Hide resolved
…her-and-switch-to-conditions-filter # Conflicts: # apps/worker/src/app/workflow/usecases/message-matcher/message-matcher.usecase.ts
What change does this PR introduce?
deprecated the use of MessageMatcher usecase and switch to ConditionsFilter usecase
Why was this change needed?
In the past we used MessageMatcher in the worked however today we ConditionsFilter in application-generic, initially made for integration but today the code is pretty much the same and they bear the same responsibility.
IMO there is no reason to have them both.
Other information (Screenshots)