Ordering constraints for output processors about workload-automation HOT 2 CLOSED

The order in which output processors (or instruments) are invoked does not depend on the order in which they are listed in the agenda. The assumption is that they are independent and chaining as you describe it is not supported. Adding something like that would in theory be possible, but given that our execution model is already pretty complex, far from trivial. Given the fairly limited utility that would provide, we cannot commit to implementing such a feature with any kind of priority.

In your specif case you have several options:

• Combine the two output processors into one. If processor B depends on the output from processor A, then it never makes sense to use it independently of it. If you want to be able to invoke the functionality of processor A without invoking the functionality of the processor B, you can always make it a configuration parameter of the combined processor.
• Add the metrics in an earlier stage. Have trace_processor add the metrics as part of process_job_output stage, and metric_plotter utilise them as part of export_job_output.
• We do have a limited ordering facility for callbacks in the form of priority decorators. You could decorate trace_processor's callback with @fast (from wa import fast) to ensure it gets invoked before callbacks with "normal" priority. (Note: this feature isn't really designed for enforcing ordering between specific augmentations; it's primary purpose is to increase precision for instrumentation by ensuring that timing-sensitive operations are not delayed by long ones; see https://workload-automation.readthedocs.io/en/latest/developer_information.html#prioritization).

from workload-automation.

Thanks a lot, switching to export_job_output did it for me (seemed less of a hack than priority decorators).

from workload-automation.