Event Get Query Match All Not Working?

I have setup an Event: Get node in a workflow using mutliple fields and match “ALL” type query. The node returns an event even though the items don’t match. What am I doing wrong here?

This is a loop workflow, so I use the mutate block to remove working.lastEvent from the payload before the Event: Get node, so there is no stale info on the payload as shown below.

2

The input is working.currentAlertSettings and the output is working.lastEventInfo. Detailed payload after the Event: Get is shown below:

    "currentAlertSettings": {
      "index": 1,
      "value": {
        "ackRequiredToClear": true,
        "attribute": "ch1pv",
        "createdAt": "2021-05-11T12:51:33.989Z",
        "deviceId": "609a7dd145c8a20006498f53",
        "deviceName": "Demo Gateway IAC",
        "enabled": true,
        "id": "609a7dd545c8a200064994b8",
        "level": 90,
        "logic": 0,
        "name": "LO Header Pressure",
        "notificationsEnabled": true,
        "severity": 3,
        "severityStr": "critical",
        "throttleEnabled": false,
        "throttleLimit": 0,
        "updatedAt": "2021-05-11T12:51:33.989Z"
      }
    },
    "currentAttribute": {
      "index": 1,
      "key": "ch1pv",
      "value": 85.46
    },
    "lastEventInfo": {
      "applicationId": "609a7dd145c8a20006498f00",
      "creationDate": "2021-06-07T20:33:03.243Z",
      "deviceId": "609a7dd145c8a20006498f53",
      "deviceName": "IAC Smart Plant Demo",
      "eventId": "60be827f35fa3f0007667fbe",
      "eventTags": {
        "ackRequiredToClear": "true",
        "attribute": "ch3pv",
        "deviceId": "609a7dd145c8a20006498f53",
        "deviceName": "Demo Gateway IAC",
        "enabled": "true",
        "level": "1.5",
        "logic": "1",
        "name": "HI Differential Pressure",
        "notificationsEnabled": "true",
        "severity": "3",
        "severityStr": "critical",
        "throttleEnabled": "false",
        "throttleLimit": "0"
      },
      "id": "60be827f35fa3f0007667fbe",
      "lastUpdated": "2021-06-07T20:33:03.389Z",
      "level": "critical",
      "message": "Limit: 1.5  Value: 3.04 Logic: 1 Severity: critical AckRequiredToClear: true",
      "sourceId": "609a7dd145c8a200064991ea",
      "sourceName": "process attribute alerts",
      "sourceType": "flow",
      "state": "new",
      "subject": "HI Differential Pressure",
      "updates": [
      ]
    }

Based on what you’ve provided here, I’m not seeing where the issue lies. While trying to figure this out, I happened to have your workflow open while a payload came through and was able to follow the logic; however, in that case, the query did return what I would expect it to return based on the values I saw.

My theory at the moment is that there is some condition in your workflow that would cause the Mutate Node that clears the last event not to run, and thus you are seeing the previous value at that payload path in your debug output. For example, you have a couple Conditional Nodes that lead into Next Nodes, which would stop that iteration. And since you are running the loop serially, changes to the payload carry over from one iteration to the next.

So, what’s happening is something like this …

  1. Iteration 0 runs. In this iteration, an event is found matching your query and is placed at working.lastEventInfo.
  2. Iteration 1 runs. Based on some conditions within that iteration, a Next Node is hit before your Mutate Node that removes the value at working.lastEventInfo. Therefore, the event found in Iteration 0 is still on the payload at that path.

Thanks Dylan, I had assumed that there was some stale info in the payload, thus I added the mutate to clear out lastEventInfo on each iteration immediately before the Event: Get node. I don’t understand how this would not happen serially.

You could do one of two things:

  1. Move that Mutate Node that clears the last value up to be the very first thing that runs within your Loop Node, or
  2. Switch your Loop Node to run in parallel mode, which would eliminate the need for clearing the previous value (as mutations to the payload do not carry through to subsequent iterations). You’ll also get a performance boost out of switching to parallel mode.