Closed TomKaltz closed 8 years ago
After some digging, found the info() function of the vm context. Very nice! This needs to be added to documentation.
@TomKaltz note that the info
property of jobs is intended to be used by external APIs w/o access to the job itself.
Within a task, you have access to the whole job object, so you can use whatever the identifiers you need to attach any additional properties to the job itself.
However, when a task of a workflow performs a call to a remote API, which in turn may need to perform an operation which may consist of either several steps or a long time period, it's desirable to have a way for that remote API to provided some feedback of the progress of the operation taking place (name of remote step happening, percentage of task completed ...). That way, the user trying to get up2date information about the workflow execution don't need to wait until the task is completely finished to get access to such info.
As you can see, it's intended to be used through HTTP requests to the end-point /jobs/:job_uuid/info
, and it's documented as part of the HTTP API and intentionally not documented as part of internal workflow docs.
Has sense?
But when my task controls the external process (a spawned executable) is it acceptable to use info()
to store progress data for the front-end user to query while the job is in-progress?
My use case is video transcoding where my task spawns an external ffmpeg process to convert a video file.
This does work for me but I want to know if I'm missing some unintended consequence of using info(progressInfo)
in this way