-
Notifications
You must be signed in to change notification settings - Fork 39
Hi! I have just started looking at the implementation of the river and the UI. It seems to be a great product; thank you very much!
I have a feature request: an ability to queue jobs from inside the UI. Have you been considering something like that?
All reactions
Replies: 2 comments
@chaporgin The biggest problem with that right now is that River UI doesn't actually know anything about your Go code, so it doesn't know which types of jobs should be available or what args they should take.
I suppose what we could do is select distinct job kinds based on what's already in the database and give you a freeform override field in case you want to enqueue a job kind that's not already in there, but we'd probably still have to provide a raw JSON field, which isn't super great.
I guess there could also be an option for when running the UI as a handler from your own code to have it take a workers bundle so it could know what's available. That might restrict it's usefulness though since probably not too many people go down that path.
I agree though that this would be a useful feature in general though.
All reactions
Odd. Responding to another comment I got in my email, but which may have been deleted since:
It would be very convenient if there was a way to start jobs directly from the UI. These jobs are already defined in the code, and we can pause or unpause them from the Queues tab in the RiverUI. This is somewhat related to this discussion, but it seems like a slightly different proposal since we already have a list of periodic jobs in the UI. What we need is a way to manually start these jobs before their scheduled CRON interval. One possible solution could be to insert them into the system so they show up as SCHEDULED, allowing us to run them in a more ad-hoc manner. After pressing manual run button, we could schedule the job to be run in 30 seconds for example.
Any thoughts? I could try preparing some PR for RiverUI to support this feature. @brandur
Again, seems somewhat plausible, although as above, River would have to read jobs out of river_job to know what sorts of jobs are available. The good news is that it'd be easier to identity periodic jobs in particular now that those are identified in metadata. Once again, args are still a bit tricky — having a simple "enqueue" button would work for periodic jobs with no args, but that'd be only some jobs and possibly a minority case.