Contains is not an operator

[Wardormeur]

Hey 👋 We've been running on an issue in regard to rules

DEBUG 173 [
  Rule {
    id: 174,
    created_at: 2025-06-04T11:55:27.000Z,
    updated_at: 2025-06-04T11:55:27.000Z,
    project_id: 2,
    uuid: 'eb6f0b4c-71e4-4064-b858-ff9232be0ef0',
    root_uuid: '805f4a7e-3ba6-4c95-8553-2008afb8cd98',
    parent_uuid: '805f4a7e-3ba6-4c95-8553-2008afb8cd98',
    type: 'array',
    group: 'user',
    path: '$.merge_fields.COUPON',
    operator: 'contains',
    value: 'CAAMAD, CAAMCO',
    result: false
  }

{"level":50,"time":1749819885855,"pid":95,"hostname":"3625f0a29260","error":{},"stacktrace":"Error: unknown operator: contains\n    at Object.check (/usr/src/app/build/rules/ArrayRule.js:17:15)\n    at check (/usr/src/app/build/rules/RuleEngine.js:45:40)\n    at predicate (/usr/src/app/build/rules/RuleService.js:51:38)\n    at Array.every (<anonymous>)\n    at checkRules (/usr/src/app/build/rules/RuleService.js:60:18)\n    at checkRootRule (/usr/src/app/build/rules/RuleService.js:78:35)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async matchingRulesForUser (/usr/src/app/build/rules/RuleService.js:126:24)\n    at async handler (/usr/src/app/build/users/UserPatchJob.js:48:29)\n    at async Queue.dequeue (/usr/src/app/build/queue/Queue.js:60:9)\n    at async worker.bullmq_1.Worker.connection [as processFn] (/usr/src/app/build/queue/RedisQueueProvider.js:77:13)\n    at async /usr/src/app/node_modules/bullmq/dist/cjs/classes/worker.js:516:32\n    at async Worker.retryIfFailed (/usr/src/app/node_modules/bullmq/dist/cjs/classes/worker.js:743:24)","job":{"name":"user_patch","data":{"

From having a look at the code, it should not be possible for a ArrayRule to have the operator 'contains' The impact is constant restart, because I believe these are checked at every user ingestion, and then retried thrice. I have no clue how we got here though, so it's a mystery for you :)

[Wardormeur]

I've found and corrected the rule in DB to fix ourselves, however that list was archived. So I'm surprised the error was still running despite us disabling the parent list