When you have a recording that is set to trim, after the trim has been submitting the status reads "waiting for trim". It then proceeds with "waiting for captions". I was on the fence whether this should be a RB but I'm concerned that users willl think the system is broken resulting in posts to matterhorn-users.
My understanding is that you had to apply some new logic to determine which operation is current. My theory is that since you're not taking into account the skipped status, and as a result the logic doesn't consider the operation after skipped as the next operation. Obviously we shouldn't show skipped operations, or defer to the previous operation if the current operation is skipped.
in general: when you see the hold operations that are skipped later on, they are in QUEUED state in the system, meaning the job associated with the operation is scheduled for execution but has not started. As soon as the actual job logic starts it reads the workflows configuration properties and immediately stops putting the operation to SKIPPED if the configuration property it acts on is not present or set to false. before one cannot tell, if the operation will actually start or be skipped (weather it should be omitted in the UI).
since today: the UI now receives a 'compact' version of the json data from the workflow endpoint. 'compact' means that a lot of data that the UI doesn't need to display (eg. alle the mediapackage elements) is not marshalled anymore so that the json becomes smaller and takes far less time to be parsed by the browser. Unfortunately also all workflow operations except the current one are also omitted, hence the workflow UI can't search for the current operation anymore, but can only display the one workflow operation the instances endpoint delivers.
I think the solution here is to change the strategy to not show an operation until it is actually running. As of now the instances endpoint has to care for this. The other option is to re-enable the whole list of operations being delivered by the endpoint so that the UI can implement the proposed logic. But the point to consider here is that it is the list of operations together with the list of mediapackage elements that makes up the biggest portion of the json data and thus is responsible for the performance issue.
downgrading this. due to limitations with the workflow service, we'd need new functionality to support multiple descriptions for a hold operation to avoid this problem. or we could ignore queued and just show operations that are currently running. but that is a later conversation.
“Ο Θεός στο μηχάνημα έχει καθορίσει αυτόματα το πρόβλημα”
This ticket has been automatically resolved due to two years of inactivity. Please re-open if this issue is still relevant.