Hi there,
I have been working on a scheduled workflow and due to some bug in my JSON transform query, I've had the email resource spammed with email send requests from the workflow. I want to know:
a) how to stop the workflow from running;
b) how to reset the email resource send queue so that I can continue testing.
Many thanks in advance,
Gus.
Currently getting this error when attempting to re-use the email service:
I think you'll have to choose between skipping the block that sends the email and deciding what the condition(s) are for when to stop a workflow. as for how to actually stop it once you know when you want to stop.... technically you can't.... what you can do to sorta mimick this however is to add a check in the setup script area:
this code is ran before a block if:
you might be using an Email Resource Query Block with no template strings:
in this case, you can see it isn't a jacascript block and there are no template strings, so the setup script code won't run here. To fix this, we simply move the email block into a function then call the function from a js block:
now the code we have in our Setup Script will run before we send an email... inside the setup script we can throw errors to prevent the workflow from continuing (we can either let this check run all the time basically before any js, or under specific conditions to prevent stopping the workflow too early on accident)
To stop the workflow, disable it in the Workflows section or temporarily revoke email resource permissions. To reset the email resource queue, access your email service dashboard, cancel pending emails if possible, or pause the email service temporarily. After fixing the JSON transform bug, re-enable the workflow and email resource to resume testing.
do you know if revoking permissions from an app stops the workflow while it's running?
I guess you could programmatically revoke access to whatever resource the workflow your app may access after calling it to force it into an error mid run. the only problem I see w this is a possible race condition where anything that tries to use the same resource right after this may also error out... w heavily nested workflow calls this could be a nightmare of a bug to find without already knowing about it's possibility (it's a brutal catch 22) as this is one of those problems that occurs based on processor load at run-time so it could be something you only see like 1 out of 5 times or whatever
