Previous expression results are not available at context for the subsequents expressions

[mapedraza]

IoT Agent Node Lib version the issue has been seen with

3.4.4 (master)

Bound or port used (API interaction)

Northbound (Provision API and NGSI Interactions)

NGSI version

NGSIv2

Are you running a container?

No, I am running it natively

Image type

None

Expected behaviour you didn't see

It is not possible to nest attributes using values from previous expressions. I.E:

            active: [
                {
                    name: 'prefix',
                    object_id: 't1',
                    type: 'text',
                    expression: '"pre_"+t'
                },
                {
                    name: 'postfix',
                    object_id: 't2',
                    type: 'text',
                    expression: 'prefix+"_post"'
                },
                {
                    name: 't',
                    object_id: 't',
                    type: 'text',
                    expression: 'null'
                }
            ]

Would not calculate postfix attribute

[mapedraza]

Tests added here: #1490

[fgalan]

I understand the typical case for nested expression is something like this:

attrA: f(measure1, measure2, ...)
attrB: f(attrA)

so I understand something in the IOTA logic has to calculate attribute dependencies and evaluate attribute functions in the right order (in this case, first attrA funciton, next attrB function).

[fgalan]

Moreover, we could (in theory) things like this:

attrA: f(attrB)
attrB: f(arrtA)

or even:

attrA: f(attrA)

I understand that IOTA should detect this situations (at group/device provision time?) and raise an "cyclical dependency" error or something like that.

[fgalan]

PR #1491

But not sure if the above PR addresses the comments I have just posted. Let's keep the issue open while we can clarify that.

[mapedraza]

IOTA Logic loops over active attributes. In case of "cyclical dependency", it should act as provisioned. IE:

Initial Values:

attrA:10
attrB:20

Provision (expressions):

attrA: f(attrB)
attrB: f(arrtA)

Final values

attrA: 20
attrB: 20

Note that provision order matters

[fgalan]

Note that provision order matters

Good point :)

Thus, the responsibility of expression evaluation order is put on the shoulders of the users. Good enough, but it should be properly documented. I'd suggest to include such documentation in PR #1490 (expanding the scope from test to test+doc).

[mapedraza]

Done at #1491