Is this behavior of Input/Output mapping expected?

Suppose I have 2 workers in my workflow => A => B =>. Before the worker A the context is {"a": {"x": 1}, "b": "2"}. A has input mapping b -> a.x (and no output mapping). A as the result sets the same context (as A input): {"a": {"x": 2}}. But B input is still the {"a": {"x": 1}, "b": "2"}, not the {"a": {"x": 2}} as expected.
If I set dummy output mapping of A as a -> a it fixes the problem.
Is this behavior expected? Am I doing something wrong?

That’s not what I would expect.

Does worker A receive {"a": {"x": 2}, "b": "2"} as its input, or something else?

Hi @road21,

It works as expected.

Let me explain what happens:

  • the instance is created with the variables a:{"x": 1} and b:"2"
  • the input mapping b -> a.x is applied and a new local variable a:{"x":"2"} is created in the scope of task A
  • the job A is activated with the variables a:{"x":"2"} and b:"2"
  • the job A is completed with the same variables
  • the job variables are propagated beginning from the scope of task A
    • variable a exists as local variable of task A and is not propagated to the workflow instance scope
    • variable b is propagated but not changed
  • the job B is activated with the variables a:{"x":"1"} and b:"2"

Read more about variable propagation in the documentation:

Does this make sense for you?

Best regards,


Thank you for explanation! Yes, It makes sense.
But when you add dummy mapping like a -> a and it changes the behavior of the program, it’s a little bit strange :slight_smile:

After the input mapping A receives {"a": {"x": 2}}

I agree that it is not intuitive. If you’re using input/output mappings then you should keep the variable scopes in mind. :sweat_smile:

The output mapping a -> a is necessary to enforce the propagation to the upper scope because of the local variable. It basically means “read the variable from the current task scope and propagate it to the upper scope”.

1 Like