#Cancellable Delayed Task
1 messages · Page 1 of 1 (latest)
When you call trigger we give you the run ID back in return. You can then use that to cancel
Is there a way to pass our own ID in some way? Would be cool if we had some sort of externalId or so to pass, and then be able to cancel through that.
Or is there a better way to achieve the scenario above? Trigger a task that waits for 2h before sending an email, but being able to reset the timer. We had looked into the schedules, were we're able to have our own ids, but schedules only worked based on a cron right now, while having a timer would be very cool ('2h')
Schedules are really for recurring tasks, not one offs.
We have tags so I would use them for this. We might add externalId but the problem with them is what happens if someone uses the same one twice?
That shouldn’t be authorized, it’s like having twice the same run_id on two runs
Maybe we should just allow loooking up runs using the idempotencyKey which is a one time thing
Point is we wanna cancel delayed runs on another run.
So we have one run that created delayed runs
And we can have 1h later another run that will cancel the delayed runs.
idempotency ain’t gonna work here
Sorry I mean we already support passing an idempotencyKey when triggering. It has to be unique which is what you were describing before. So if you could cancel using that it seems like that would be a good solution in the future
For now you’ll have to use tags btw
Or store the run IDs
Yes my initial solution was about using tags. However I found out an issue when listing tags with an array of string using your sdk; it returns the runs when one of the tags match instead of checking if all tags in the input match all the tags on the run
Yeah all our filters are OR not AND
If your tags are the UUIDs isn’t it just one tag anyway?
We’re going to add support for cancelling multiple runs using filters quite soon. So you don’t have to first list them
I was using two ids (user id, and another unique id), I’ll find a way to combine both of them for now
We should just support sending external id when triggering a task
Yeah that makes sense. It won’t be this week though @light minnow so for now use tags and we’ll update you when it’s been added
Thanks appreciate
Thanks @livid plume @exotic kernel , I'm happy with externalIds or idempotencyKey cancelling!
Or maybe we could do a cancellationToken instead
hm, i guess that would work, as long as we can pass it freely. but it seems like external id or idempotency key is the best solution, since it could be used for other things like looking up the task.
temporal had a cool feature, WorkflowIdReusePolicy, which allows you to define exactly what should happen if the given id collides.
client.workflow.start('some-workflow', {
workflowIdReusePolicy: WorkflowIdReusePolicy.WORKFLOW_ID_REUSE_POLICY_TERMINATE_IF_RUNNING.
})
the values are
export declare enum WorkflowIdReusePolicy {
/**
* No need to use this.
*
* (If a `WorkflowIdReusePolicy` is set to this, or is not set at all, the default value will be used.)
*/
WORKFLOW_ID_REUSE_POLICY_UNSPECIFIED = 0,
/**
* The Workflow can be started if the previous Workflow is in a Closed state.
* @default
*/
WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE = 1,
/**
* The Workflow can be started if the previous Workflow is in a Closed state that is not Completed.
*/
WORKFLOW_ID_REUSE_POLICY_ALLOW_DUPLICATE_FAILED_ONLY = 2,
/**
* The Workflow cannot be started.
*/
WORKFLOW_ID_REUSE_POLICY_REJECT_DUPLICATE = 3,
/**
* Terminate the current workflow if one is already running.
*/
WORKFLOW_ID_REUSE_POLICY_TERMINATE_IF_RUNNING = 4
}
@exotic kernel
this could work well with externalId
what do you think @livid plume ?