Assign activity in 'Parallel For Each' being shared across threads/not reevaluating

Feedback Activities
, , , ,
#1

Hi,

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.

image
image961×414 13.5 KB

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?

Thanks for any help,

Gareth

#2

Hi @g.ward,
Are you able to show example of your “Parallel For Each” loop and how it’s built?

#3

It would indeed help to have a sample of your project that reproduces this issue :slight_smile:
Could you also check your version of the activity packages? I tested a simple scenario and it worked as expected:

image
image1295×822 31.4 KB

My packages:
image

#4

HI Maciej,

I’m afraid I cannot post it here, it has a lot of sensitive info in it.

This issue has been rearing its head again, where queue items are being effected, its rather baffling.

It seems to happen when there are a great deal of threads running at any given time (say 50+), I wonder if thats related to the cause?

Also my persistence package version is v1.1.9, ill see if downgrading helps

#5

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.

#6

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.

#7

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.