i’m building toy projects while learning about n8n. this question came up when i tried to provide an “unsubscribe” link to someone who has signed up to receive daily / weekly inspirational emails
“unsubscribe” in this case would just stop the execution of the workflow
but i don’t see any way to do that via API – I can only delete an execution
what I really want to do is set a variable that is visible inside the workflow from outside the current execution context. like, if i add a webhook trigger and call it (GET webhook) then i want to set a variable like “cancelled” or whatever that is checked on the next iteration of the loop inside the workflow
What is the error message (if any)?
none, no errors in this case
Please share your workflow
Share the output returned by the last node
this is not applicable here
Information on your n8n setup
n8n version: 1.68.1
Database (default: SQLite):. SQLite
n8n EXECUTIONS_PROCESS setting (default: own, main): main
Running n8n via (Docker, npm, n8n cloud, desktop app): Docker on render.com
If the workflow is waiting you can just delete it from the execution view and it will stop.
If you wanted to build a canceled option into the flow that can be set outside of n8n it would be worth using something like redis, you could set a key as the execution id and set the value to true or false and check that on each loop to see if it should stop running.
Thanks @Jon – yes I’m aware that I can delete via execution list UI and also via API.
I also understand that I can externalise some flag that can be written from outside the instance and read from inside the instance to stop if false, or whatever I set it to. But this means holding data outside the instance which would require more technology just to hold a boolean per instance.
I’m pretty sure I can also just use something like this npm kv-storage package to save the data per instance with a dynamic key of cancel-key_{{$execution.id}} and a boolean value of false that I can set to true via API or another workflow – but again, here we have more tech to set a boolean. I think even if the server is restarted, any stopped workflows would remain stopped and any running workflows would not misbehave because i can set the value to a default false before the wait and continue on error if value isn’t found (a change to the design I shared above).
My ideal case is more like the following (because it’s 1:1 with the workflow instance so therefore easier to reason about and maintain) …
What I’m actually looking for is something exactly like the STOP button when testing a workflow, the little square. It seems to put the workflow in a “Cancelled” state but I don’t see this capability exposed in the API or anywhere else in the user interface of n8n
Here’s a screenshot of a workflow being tested with the little Cancel test square button and then a snippet of the Executions list showing the instance in a Cancelled state
Hey @amgando It was great speaking with you at the hangout.
This is how I would implement your workflow using the Scheduled Trigger as I mentioned.
difference is it doesnt require an execution to be “active” 24/7 hence there is no need to cancel or stop an execution. Which are concepts your users should really need to worry about!
I don’t think you can escape the use of a “database” for these types of workflows. Doing so granted can yield creative results but perhaps not recommended if there are obvious drawbacks.
Thanks Jim – this is a totally different way of looking at the flow, thanks for sharing.
So instead of relating each user subscription to a running instance as 1:1, you chose to batch all user runs using 3 separate workflows like tools and then put them all into the same canvas which looks like it was easy to document and for me easy to understand.
i can also see how i could use airtable to exernalize the subscription flag if i wanted to keep things as one instance per subscriber
i can’t think of any obvious pros / cons to either approach, thinking “looking from above” like you have or thinking “walking the path” like i have. your instance history would be a mixed bag of different calls, mine would match subscribers, we both would have to maintain a single workflow document, i think your maintenance would be easier between executions while mine would break unless properly migrated after stopping all running instances and launching updated ones – that counts as a big loss of time and added complexity against my design and in favor of yours.
