I have a retool workflow which triggers on linear webhook which triggers an agent to scan for duplicate issues and issue quality, and replies/updates a message.
The issue is that when a user edits the issue twice, and say, the first workflow triggered agent is still running, we end up running two agents in parallel, but the truth is i want to cancel the first invokation of the agent and only allow the second agent to continue running.
I want to uniquely key this by the issue id.
I think I could maybe do this with help from postgres, simply checking/writing to a row before/after invocation, but i can't seem to figure out a way to actually cancel the agent run from a workflow. any other approaches im open to as well to solve my problem here
Retool Workflows don’t really give you a built-in way to cancel a previous run, so when multiple webhooks come in quickly (like when someone edits a Linear issue twice), you can end up with multiple runs overlapping, which it sounds like is exactly what’s happening.
The main workaround I’ve used is to handle it externally, usually with a small coordination layer in Postgres. You basically treat it like a lock or a flag to say “an agent is already working on this issue ID,” and only the most recent one should keep going.
The pattern goes something like this:
When the workflow starts, upsert a row into a table (keyed by issue ID) with a timestamp or a run ID.
Pause briefly (like 500ms), then check the table again to see if your run is still the latest.
If not, just exit early and don’t run the agent.
If it is, continue with the agent, and update the row at the end.
So you’re not actually canceling the previous agent, you’re just letting the latest one through and making the earlier one quit if something newer has come in. It works pretty reliably for this kind of thing.
If you have Redis available, that makes it a little easier (just using a key with TTL), but Postgres works fine too.
hmm I don't think so, there’s currently no built-in way in Retool to cancel an agent invocation from a workflow, even in self-hosted or enterprise environments.
Once an agent is triggered (either via a block inside a Workflow, an API, or a webhook), it runs to completion, and there’s no exposed method or API in Retool to terminate or cancel it from another place.
To cancel a Linear agent run from a workflow, you can't directly terminate an existing run, but you can design around it. Use a database (like Postgres) to store the latest agent run keyed by issue ID with a timestamp or unique token. When a new webhook triggers, check the database—if a newer run exists, the older agent checks and gracefully exits early. This requires the agent to periodically check if it's still the latest run. This "soft cancel" approach avoids race conditions and ensures only the latest invocation proceeds, effectively simulating cancellation behavior.
Have logic in the workflow check first to see if data exists in a DB table that represents a previous agent run for the corresponding ID. If none is created, run the agent and create the ID so that the next trigger will detect this and not run unnecessarily.