Random behavior from pipeline when trying to work/split on multi-level json data


Used assets
Sample input xml below
multiplemstercpttoub454.txt (51.1 KB)
Problematic pipeline asset below
but_why.slp (67.8 KB)
(you may want to remove the splunk, producer etc snaps if connection is unavailable during investigation)

Requirement context around which the problematic random behavior identified:
In input xml, following two tags may repeat any number of times:

Now the need was to split this xml into individual xml containing one of each from above tags… then transform those xml into a plain text for output

Logic was to ensure both of these are treated as arrays (so even when there is just one value for repeating tags, we would still be able to loop through them after transforming them as array else the same expression may not work for both arrays and map) and split them in order keeping the parent values intact

Random behavior… some times it gives correct 2 outputs where expqty != rcvqty but sometimes… same message is repeated twice!?.

Screenshot highlighting areas of interest:

Working run details (when the behavior is correct per expectations):
This time the two outputs are per expectation:
Check the output from 3

So there were two records in input with expqty != rcvqty and those data were correctly split and processed.

Note the outputs at 1

Note the outputs at 2

The input and output preview at 2

Now tried re-validating a few times until the random wrong behavior kicks in…

Incorrect run details (when the result is wrong)
This time the two outputs are wrong. Same message got processed twice:
Check the output from 3

So there were two records in input with expqty != rcvqty and one of the records gets repeated…

Note the outputs at 1
The behavior is correct till here.
It messes at 2

Note the outputs at 2

Input and output preview at 2

How did the value of this tag get swapped? And this happens randomly

Extra notes
a. I tried different approaches at the point 1 like using mapper, structure etc but the random behavior still persisted.
b. As a last resort I had to handle all splitting operation (all of it) within script so the output is always correct… but I am still interested to know the reason for this behavior and a better solution if there is one