Yup, that works.
And if I pass different variable from the error block, it seems to work:
The fact that this works but it does not recognize the workflowContext.currentRun.error.message property makes me think that there may be a dependency issue. Export your Workflow as JSON and attach it here or send it to me in a DM, I'll test it on my end. Your resource configurations will not be exported, you don't have to worry about your Slack credentials.
Similarly, could you try running my workflow with your channel name/id? You may need to connect to the Resource, it should be quick if you connect with OAuth.
Paulo - Slack Test (1).json (16.5 KB)
I'm sorry for having you do all this extra work. From what I'm seeing, the Workflow should work with your current configuration.
If this worked, there must have been a dependency issue at some point along the way. This is rare and unfortunate, they usually go away with a hard refresh but in your case, that issue has lingered for quite some time.
Creating a new Workflow or using mine as a starting point may be the best solution this issue.
Update: Just noticed your Workflow has many more steps than I thought. I'll do some digging, maybe there is something else happening along the way.
Good to know there is a fix. Unfortunately, I have built 3 complex workflows off of this workflow... Bummer to have to rebuild all of them.
We may not need to, if the issue is related to one of the steps, recreating it will give us the same results.
1 Like
First test went great, the JS did return the correct error. Although the error is just showing that I don't have that resource, it means it is not a dependency error. 
I'll try the Slack API next.
Success:
This confirms it's not a dependency issue. Something must be happening along the way that is clearing the error object causing the undefined, or populating it with an object, causing the [object Object]. Although I do not have your Resources, I'll try running something similar to what you have.
I'm using the native Slack connection and just writing into a blocks. Here is the main part of it:
[
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*{{action}}*\n>{{comment}}"
},
"accessory": {
"type": "button",
"text": {
"type": "plain_text",
"emoji": true,
"text": "{{cta}}"
},
"url": "{{url}}"
}
}
]
The fact that this issue still happened when you used the standard message send block:
gives me confidence that the issue is not caused by the Slack query you are importing from the QL. We could try what you did here, but disconnecting the imported query and only using the "query1" block to confirm this theory.
I've escalated this issue to my team internally, we'll get back to you soon. I'll do some testing on your export in the meantime.
Thank you for your patience!
Thanks for tackling this!
2 Likes
If it's useful, i'm seeing other strange behavior on this workflow that also seems to be potentially related to dependencies.
This second block is not always able to use values from startTrigger. Its about 30%-50% successful while i'm testing.
Also, while trying to add another block, i can't seem to reference the tld block now either. I even tried adding the new block directly to the tld block and it still gives me a null response.
does the problem persist if you try creating a new block, copying the code over then deleting the old one?
From looking at the "tld" block, you have access to tld.data which looks like:
tld.data: {
domain: "skimos.fr",
subdomain: "123",
tld: "fr"
}
In "query1" you could do tld.data.domain , tld.data.subdomain, or tld.data.tld but tld.domain.name does seem to be undefined.
My teammate recommends doing a console.log with the higher JSON path in the error block, We should get more clarity on this. In other words, have your error just run a console.log(workflowContext.currentRun.error). When you run the whole workflow, let's look at the log and how that object looks like.
We have a workflow set up to post errors to a slack channel.
Occasionally we see failed runs where the error is undefined and the input data is logged as [object object]
Slack error handler:
Resulting error:
On looking at the logs for these runs we can see that all the steps log out as if run successfully, but are flagged as skipped. On checking our database it appears none of the steps actually ran
Run logs:
If we re-run based on the same input there doesnt seem to be a problem at all. Can you help us figure out what's going on here?
Other errors are being caught and logged appropriately, but we can't seem to track down the source of this kind.