syntxerror
commented
1 year ago Hi @Kiddinglife. We're circling back on this issue and wondering why you might need two directors that work on separate string filters? Is this a scaling issue you're trying to avoid?
If you're trying to shard these players in two directors to avoid overlapping tickets then this may be the wrong approach. It seems as though there are two unique groups you're defining that can have similar filters but in fact they are different and you would like to avoid mixing and creating overlapping profiles. We can call them A (k1:v1) and B(k1:v1 & k2:v2) Let's consider this example: Profile 1 matches on Tickets A Profile 2 matches on Tickets B
You would get overlapping profiles because of the filters presented in the tickets but to shard them further we can use tags.
Let's say: Tickets A are queuing for Mode A Tickets B are queuing for Mode B
These are unique enough to create separate profiles and no longer need two directors. These modes are also hypothetical tags that are used for this scenario and can be replaced with anything else such as region, role, or if you want to use your example above, director1/director2.
Hopefully this helps but we do not recommend multiple directors unless your backend infra absolutely calls for this. Up to you there.
Is your feature request related to a problem? Please describe. I'm always frustrated when I need "exact selection" of the tickets based on string and tag filters. For example, I have two directors - one with string filters k1:v1 and the other with string filter (k1:v1 and k2:v2). Baed on open match documentation, I will have overlaped tickets with (k1:v1 and k2:v2) in the matches fetched by director 1 and 2.
Describe the solution you'd like I want to have no overlaped tickets with (k1:v1 and k2:v2). I need a new ticket selection rule that takes all the tag and string equal filters as a whole. for example, a profile with a string filter k1:v1 can only select tickets with filter k1:v1. It should not select tickets with two string filters k1:v1 and k2:v2
Describe alternatives you've considered I am now aggregate all the string filters into a single string filter.
Say we have the below match profiles: Profile1 has a Pool that filters all Tickets with string equal filters k1:v1 and k2:v2 Profile2 has a Pool that filters all Tickets with string equal filter k2:v2
The overlapped tickets will be those with string equal filters (k1:v1 and k2:v2) To avoid the overlapped tickets, we can aggregate all the filters in Profile1 into a new single string equal filter that looks like: Profile1 has a Pool that filters all Tickets with string equal filter k12:v12 Profile2 has a Pool that filters all Tickets with string equal filter k2:v2
Also if two profiles having same filter after aggregation, we just use one of them to fetch matches to avoid conflicts further. Also we need do the aggregation of the filters before calling the froentend api to create the tickets.
The filter aggregation works easily with tag and string filter. But for double range filter, if all possible values in that range are pre-known, we can still aggregate those filters. But if all possible values in that range are NOT known or cannot be predicted, aggregation is impossible. In such case, have to rely on evaluator to eliminate the match conflicts.
Additional context the original multi filters can be called "relax selection" where filters 1 can select tickets with filters (1 and 2) or 1. The trick here is to keep the AND relations of all the filters but with a single filter entry, which can eliminate the conflicts due to the open match's ticket selection rule that a ticket can be selected if the number of pool filters are <= those in the ticket itself.