If a step of a flow is assigned to a worker tag that does not exist
I don't understand the issue you're having apart from the fact that cancelling flows that have started do require a worker with the proper tag
5 Replies
If a step of a flow is assigned to a worker tag that does not exist, it will stay as queued forever
Then when trying to mass-cancel them from the batch actions UI, it does not work unless if i go into each individual job and cancel, then force-cancel it
I will look into it, flows that haven't started should be cancellable directly
are you sure they're not mid-running?
like they started their first step?
Some of the flows that the job/step belongs to are stopped, some are still running right now as of 23 days ago, but the bugged jobs are always orange.
Also another reason why I assumed it was a hack is I had to patch my cli to inject
tag: $args[_worker_tag] into flow steps and scripts when pushing
Without doing this you cannot do flows that provision persistent machines/workers and assign them jobs, because for some reason tag selector only lets you select manually created tagsyou can absolutely use those tags, you just need to first create them as custom tags with the $args part
Or rather you can, but its not intuitive and a bit painful to do it each time.
I think for any use case that involves persistent unique workers, this is the only major point of confusion for learning how to orchestrate them in windmill
Example:
Just installed windmill. I have a linode vm with a worker on tag linode-1. I want to run u/admin/fibonacci_script on just linode-1.
If I was just using the typescript client, this would be trivial, but if I am using the UI, I need to Edit Script -> Settings -> Worker group tag (queue) -> Custom Tags -> $args[_worker_tag] -> Add -> Select the tag -> Deploy -> fill in tag in input args and run the script
It now wont work when I want to run the script on a normal worker without specifying the tag parameter.
I understand why custom tags UI exists, but If someone already has permission to run a script using a certain worker tag, there must be a better way.
I personally found it much easier to just automatically push all scripts with $args[_worker_tag] set, and _worker_tag parameter placeholder set to python3, bash, etc. regardless of if it is actually a parameter in the script.
This way, if I want to run any given script/flow on a specific worker tag, I dont need to edit and redeploy the script/flow itself, I dont even need to add a main(_worker_tag: str)! It works even if the script does not expect it!
It is hard to convey but I suspect new users will assume that windmill really does not like unique workers, because you seemingly cannot just take a script and run it on a specific VM's worker without extra steps
@rubenf
TLDR, I propose:
In flow editor:
(fast to implement)
- move the tag selector to Advanced -> Tag, make it able to be provided an arbitrary value, with a 'OR use a dynamic expression' under it.
OR
(ideal)
- Move tag selector into Step Input, in the empty space flanking the Fill Inputs button. Add a optional expression button
- Tag editable on the runnable's interface, prefilled to default
- No errors if it is not using a predefined custom tag. This blocks temp workers. If it's a permission issue, don't allow them to adjust the tag unless they can edit the script or create the custom tag, which they'd otherwise need to manually do.
- Tag editable when running the script/flow, prefilled to the default tag.
Now you can do
Without many intermediate steps
If I was not so busy id PR this myself as it was major and frequent pain point for me
Maybe not practical for some reason I havent thought of but wanted to provide something concrete