How do you extract a Watcher's 'state', 'status' or 'execution_state' from ctx

[ameindel]

Hello there!

I'm currently trying to create a Watcher that has a 'condition' that will resolve to true when the Watcher execution fails (checks for a "failed" state). I have a Teams webhook that works, and I would like that webhook to be invoked if the Watcher, when run, fails for whatever reason.

So far I've tried combinations of:

ctx.payload.hits.hits.0._source.state
ctx.payload.hits.hits.0._source.result.input.status
ctx.payload.hits.hits.0.fields.status.execution_state

Any guidance would be greatly appreciated.

Thanks in advance,
Adam

[ameindel]

Additional context - I should mention that this is an HTTP input-only Watcher that does not utilize any searches. It simply makes an HTTP GET command to an endpoint. The goal is to eventually create a Dashboard that will retrieve the payload data stored in the .watcher-history index.

I'd like Watcher 'condition' logic to resolve to true if, say a GET to the endpoint fails (which results in a 'state' being set to 'failed').

I've noticed that my HTTP Watcher's response has a null value under 'resolved_values' for 'state'. When I do a 'normal' Watcher that utilizes a search, I get a value back for that field. This leads me to believe that an HTTP Watcher that doesn't use a search has no execution context (ctx)?

So my refined question I suppose would be - is there a way to extract out the 'state' from an HTTP input-only Watcher?

[richcollier]

An HTTP input does not product the hits array like the search input does.

Look at this simple example:

POST _watcher/watch/_execute
{
  "watch": {
    "trigger": {
      "schedule": {
        "interval": "1m"
      }
    },
    "input": {
      "http": {
        "request": {
          "host": "reqres.in",
          "scheme": "https",
          "port": 443,
          "path": "/api/users/2"
        }
      }
    },
    "condition": {
      "compare": {
        "ctx.payload.data.id": {
          "eq": 2
        }
      }
    },
    "actions": {
      "log": {
        "logging": {
          "text": "found user and their email is {{ctx.payload.data.email}}"
        }
      }
    }
  }
}

Note that the result is stored in ctx.payload and that in my case, the interesting bits are in the data section:

In this example, I just spit out the user's email address gleaned from the API call

[ameindel]

Hi, Rich.

Thank you very much for your response. This cleared up some misunderstandings I had on how a Watcher-involved ctx is populated, depending on the context of usage (search input or http input).

To get around my original issue, I simply created another Watcher (to watch the original Watcher). This new Watcher utilizes a search input, which returns the latest execution document from the .watcher-history index, and it digs for the 'status' successfully.

Thanks again!