5

I have a logic app that uses For_each to iterate through email attachments and saves them to an Azure Files container.

Depending on some conditions, I want the attachment stored with a different name or at a different path, but the default concurrency of for_each is concerning; I have path and file name variables set at top level and I'm setting them in the loop as conditions are met.

Is there a way to be sure that these variables will hold the value I'm setting in that iteration without setting concurrency to 1?

It seems like it's working correctly with default concurrency, but I'm going to set concurrency to 1 until I'm sure about whether or not these iterations can interfere with each other in terms of setting variables.

spongessuck
  • 1,023
  • 8
  • 23

2 Answers2

6

If you are changing the variable value inside the for-each loop (and potentially also consuming it in the same loop), you should set concurrency to 1 to ensure the loop runs in a sequential fashion to avoid racing conditions.

Derek Li
  • 3,089
  • 2
  • 25
  • 38
  • OK, thanks. Is this documented anywhere? Are there any plans to address this shortcoming? – spongessuck Feb 02 '18 at 14:29
  • What do you consider as a shortcoming? The behavior is by-designed. – Derek Li Feb 02 '18 at 18:47
  • 6
    The shortcoming is only being able to declare 'global' variables, making the concurrency feature of For_each useless if those variables are being changed in each iteration. – spongessuck Feb 02 '18 at 20:38
1

Since variables can be declared only on top level, this will not be used on some scenarios without settings concurrency to 1. Consider we have JSON with this schema:

`[
   {
    [JSON Object]
   }
 ]`

and needs to iterate each inner to get value and increase the counter and based on counter we have some action. In this condition, we require local variable instead of global variables.

emrepun
  • 2,496
  • 2
  • 15
  • 33
Prigail
  • 11
  • 1