Check Existing Issues
Expected Behavior
mql wildcard matching should respect every literal segment of a pattern, and the IN / NOT IN operators should evaluate safely regardless of the value's concrete type.
Actual Behavior
Two problems in mql/expr.go:
1. wildcardMatch ignores everything between the first and last * (mql/expr.go:78-90).
func wildcardMatch(value, pattern string) bool {
pattern = strings.ToLower(pattern)
value = strings.ToLower(value)
if strings.Contains(pattern, "*") {
parts := strings.Split(pattern, "*")
starts := parts[0]
ends := parts[len(parts)-1]
return strings.HasPrefix(value, starts) && strings.HasSuffix(value, ends)
}
return value == pattern
}
For a multi-wildcard pattern like a*b*c, only parts[0] (a) and parts[len-1] (c) are checked. The middle segment b is silently dropped, so aXc matches a*b*c even though it shouldn't. This produces false positives in any filter that uses interior wildcards.
2. Unguarded type assertions in IN / NOT IN (mql/expr.go:66 and :73).
return listContains(e.Value.([]string), fmt.Sprintf("%v", val))
If e.Value is not a []string, this panics rather than returning a clean evaluation/parse error.
Steps to Reproduce
- Build an MQL filter with an interior wildcard, e.g.
name:a*b*c.
- Evaluate it against the value
aXc.
- Observe it matches (it should not).
- Separately, drive an
IN expression whose Value is not a []string and observe a panic at mql/expr.go:66.
Logs & Screenshots
n/a — logic bug, reproducible by unit test. There is currently no mql/*_test.go, so neither case is covered (see the related test-coverage issue).
Additional Information
Suggested direction:
- Implement true multi-segment wildcard matching (verify each segment appears in order, anchoring first/last).
- Use comma-ok assertions (
v, ok := e.Value.([]string)) and fail gracefully.
- Add
mql/expr_test.go covering interior wildcards, leading/trailing wildcards, and non-[]string IN values.
Found during a general audit of the library. Severity: high (core filter correctness + panic path).
Check Existing Issues
Expected Behavior
mqlwildcard matching should respect every literal segment of a pattern, and theIN/NOT INoperators should evaluate safely regardless of the value's concrete type.Actual Behavior
Two problems in
mql/expr.go:1.
wildcardMatchignores everything between the first and last*(mql/expr.go:78-90).For a multi-wildcard pattern like
a*b*c, onlyparts[0](a) andparts[len-1](c) are checked. The middle segmentbis silently dropped, soaXcmatchesa*b*ceven though it shouldn't. This produces false positives in any filter that uses interior wildcards.2. Unguarded type assertions in
IN/NOT IN(mql/expr.go:66and:73).If
e.Valueis not a[]string, this panics rather than returning a clean evaluation/parse error.Steps to Reproduce
name:a*b*c.aXc.INexpression whoseValueis not a[]stringand observe a panic atmql/expr.go:66.Logs & Screenshots
n/a — logic bug, reproducible by unit test. There is currently no
mql/*_test.go, so neither case is covered (see the related test-coverage issue).Additional Information
Suggested direction:
v, ok := e.Value.([]string)) and fail gracefully.mql/expr_test.gocovering interior wildcards, leading/trailing wildcards, and non-[]stringINvalues.Found during a general audit of the library. Severity: high (core filter correctness + panic path).