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
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?
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
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!