Variable Leaks


I’m facing an issue in my flow service in which data appears to be leaking. I suspect it’s due to variables somehow being implicitly connected throughout the flow service, resulting in values being passed around unexpectedly.

The general structure of the flow service is such:

  1. Parent flow service “AA”, along with child flow services “A” and “B”.
  2. Within “AA”, child service “A” occurs before child service “B”.
  3. Both “A” and “B” use a commonly named document variable called “S5” within their respective services.
  4. Parent flow service “AA” also has a document variable called “S5”.
  5. In both “A” and “B”, “S5” has two child variables “S5-01” and “S5-02”.
  6. Before “S5” is passed to the parent service “AA”, “S5” is renamed. “A” passes “S5” to “AA” with a new name “S5A” and “B” passes “S5” to “AA” with a new name “S5B”.
  7. “S5A” is appended via appendToDocumentList to “AA’s” “S5”.
  8. “S5B” is appended via appendToDocumentList to “AA’s” “S5”.

Next, in testing:

  1. The “S5” variables in “A” are assigned the following values: “S5-01” = “Jon” and “S5-02” = “JonEmail”.
  2. The “S5” variables in “B” are assigned the following values: “S5-01” = “Greg”. There is no assignment of “S5-02” in “B”.

The debug log shows the following:

  1. Within the “A” service step, “A’s” “S5-01” shows as “Jon” and “S5-02” shows as “JonEmail”.
  2. Within the “B” service step, “B’s” “S5-01” shows as “Greg” and “S5-02” shows as “JonEmail”.

“AA” outputs the following “S5” records:

  1. “S5-01” = “Greg” and “S5-02” = “JonEmail”.
  2. “S5-01” = “Greg” and “S5-02” = “JonEmail”.

The values in the child services appear to be being passed between each other. Could this be due to the commonly named variables within “A” and “B”, along with the fact that “AA” has a variable of the same name as well?

Has anyone encountered this issue before?



The behaviour is expected. The things will be immediately clear to you if you remember that documents are references to objects. If you “rename” a document, you have the same object, just stored under other name in the pipeline. So if you modify the “new” document, you really modify the original.

If you have some experience in Java, you’ll immediately understand what’s going on.

To make the new document really new, i.e. independent of the original, you have to make a deep copy. You can clone or you can assign the fields one by one (and not map the whole document). But watch out that the fields are atomic values. Otherwise you’ll have two documents having the same object as field value.

Hi fml2,

Thanks for your reply. In the end, implementing pub.flow:clearPipeline at the end of each child service appeared to fix the issue.



Usually, this does not help if you make mapping using the whole documents. Whether you make clearPipeline or not, the object is passed by reference and hence is modified. This is often a source of confusion for new wM users.

But your case is apparently different.