[🐛 Bug]: Enrichments vs CEL comparison

[diegovb-sys]

Describe the bug
Mapping or another enrichment feature allows us to modify some parameters regarding the original alert. Nevertheless, when we are handling different types to string, this could cause problems.In the next section, I show an example.

To Reproduce
Steps to reproduce the behavior:

1. Creating a Mapping to enrich with dismissed==true
2. Creating a WF/Incident with the CEL -> cel: 'dismissed==true'
3. Check the logs

Expected behavior
The expected behavior is to have a WF(Incident) CEL evaluation.

Screenshots

[dosubot]

This bug happens because enrichment (Mapping) can set alert fields like dismissed as a string (e.g., "true") instead of a boolean (true), but CEL evaluation expects strict type matching. When you use a CEL expression like dismissed == true, the rules engine tries to compare a string to a boolean, which causes a TypeError in the CEL engine—there's no automatic type coercion for boolean/string mismatches in the current implementation. The code only tries to coerce int/str types for CEL comparisons, not booleans and strings, so this error isn't handled gracefully source.

To avoid this, make sure your enrichment sets dismissed as a boolean value, not a string. For example, use true (without quotes) in your mapping/enrichment config, not "true". There's no built-in validation or coercion for this in Keep right now, so it's up to the workflow/mapping author to ensure types match what CEL expects source.

If you need to check for string values in CEL, you can use type-aware expressions or convert your enrichment logic to set the correct type. For similar issues (like list vs string), the recommended workaround is to use CEL functions like contains instead of direct equality source.

Let me know if you want more details on how to configure your mapping or enrichment to enforce boolean types!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}