Getting an annoying issue where if I assign a variable at the start of a parallel for each as part of an orchestration process, that variable doesn’t appear to get reassigned for each individual thread.
For example, I want a documentname variable to store the value from system.io.path.GetFileName(Order), where order is the full file path of a document to be processed. Using the resulting documentname variable gives all subsequent threads the same value, as you can see in this screenshot where 30162646.pdf is repeated.
Interestingly, I can avoid the problem by not using Assign, and instead just calling system.io.path.GetFileName(Order) each time, which appears to force it to reevaluate, as you can see from the “Classifying: <>” part of the above screenshot.
Is this a bug, or is there some setting I am unaware of?
It would indeed help to have a sample of your project that reproduces this issue
Could you also check your version of the activity packages? I tested a simple scenario and it worked as expected:
Understandable and thank you for extra context. It would still help a lot if you could share a sample fresh project that uses minimum activities that reproduces this behaviour.
I will do my best to get this over tomorrow - It has got to the point that blank variables are passing checks they shouldn’t when multiple threads run, but send them alone, and they work as expected.
Ok, I have just made a discovery that I think explains all this weirdness - there were some ‘write text file’ activities in the parallel for each part for debugging purposes, as soon as I disabled those the problem disappeared. I know you aren’t supposed to use delays, but I wasn’t aware that write activities should be avoided, since they don’t involve UI interaction.
Similarly, in the previous example, there is a stage at the start of the parallel for each where the bot uploads a file to the bucket. I suspect this might have something to do with the behaviour shown there, I will keep testing this theory and update as soon as I can.