Affects Version/s: 3.10.3, 3.15.1, 3.15.0-2
Fix Version/s: None
Component/s: Built-in functions
We have a custom library which consumes JSON files, merges them together, and then exposes their contents as variables in a specific bundle. We then use those bundle variables for templating.
Creating the bundle variables is done as follows:
In 3.10.2 and prior, this worked for all data types. The resulting variables could be scalars, slists, or data containers. This is helpful for templating - the variable can be as simple or complex as required depending on the needs of that specific template.
In 3.10.3 and later, for any key such that "data1[$(keys1)]" is a scalar, the final line fails with the message: "data1[key] is not mergeable as it it not a container".
This appears to be a result of commit 641c404542f98a67fd092c8bc8a901f27fb1c0f0 for issue
CFE-2704. That commit/issue addressed a problem with the multi-argument use of mergedata( ... ). However, the fix also changed the functionality of the single-argument usage invoked by @( ... ).
The fix may also have introduced a regression when merging of classic arrays, as noted in
CFE-2704. However, the specific issue affecting us is the single-argument usage of @( ... ) when collecting a scalar value from within a data container.
A fix for our use case could either revert the single-argument functionality of @( ... ) or provide a replacement function with equivalent functionality.
I believe this is a minimal policy example of the regression:
It works fine in 3.10.2 and earlier:
It fails with errors on 3.10.3 and newer (including 3.15.1):