fix: attribute loss when updating entity

[GuillaumeOd]

related to #1660

[AlvaroVega]

As a commented here #1660 (comment) a test case about his issue is needed.

[fgalan]

@GuillaumeOd please have a look to documentation in the case it has to change to describe the new behaviour with this PR.

[AlvaroVega]

This PR is reverting this commit: 166f771

[fgalan]

@GuillaumeOd not sure if I'm getting the point...

You want to send measures like this:

{
  "fireDetectionThreshold": 10
}

and get corresponding attribute at CB this way:

                    "fireDetectionThreshold": {
                        type: "Number",
                        value: 10
                    }

is my interpretation correct?

[GuillaumeOd]

@fgalan Yes, exactly! Regarding the type, I'm not entirely sure if it should be Number or Text, but your interpretation seems spot on.

Could you try running the test locally without my fix to confirm it fails as expected?

[fgalan]

@fgalan Yes, exactly! Regarding the type, I'm not entirely sure if it should be Number or Text, but your interpretation seems spot on.

In that case, why don't use at provisioning time

                            {
                                name: 'fireDetectionThreshold',
                                type: 'Number'
                            }

instead of

                            {
                                object_id: 'f_dt',
                                name: 'fireDetectionThreshold',
                                type: 'Number'
                            }

?

[tzzed]

@fgalan we already send data like this

{
    "fireDetectionThreshold": 10
}

or by using the oid:

{
    "f_t": 10
}

since the version 4.0 it does not work. So after the fix of @GuillaumeOd both works. Why did you change this functionnality?
We really need this fix? In case of devices that use oid the iot agent does not support it anymore.
You can see the test of @GuillaumeOd and try it without the fix.
Thank you again.

[fgalan]

@fgalan we already send data like this

{
    "fireDetectionThreshold": 10
}

or by using the oid:

{
    "f_t": 10
}

since the version 4.0 it does not work. So after the fix of @GuillaumeOd both works. Why did you change this functionnality? We really need this fix? In case of devices that use oid the iot agent does not support it anymore. You can see the test of @GuillaumeOd and try it without the fix. Thank you again.

So, you mean that you have some devices that are sending like "f_t": 10 and at the same time you have some other devices that are sending like "fireDetectionThreshold": 10.

Is my understanding correct?

[tzzed]

Yes exactly. Somes use object_id and othes use the name.

[fgalan]

OK. Much clearer now :) Thanks!

since the version 4.0 it does not work. So after the fix of @GuillaumeOd both works. Why did you change this functionnality? We really need this fix? In case of devices that use oid the iot agent does not support it anymore. You can see the test of @GuillaumeOd and try it without the fix. Thank you again.

It was not an intentional change (but not within our use cases, so it was not noticed by us).

Thus, the PR is ok, as long as:

1. Merge master on this PR's branch to check all test keep working
2. This patch on the library has to be checked with IOTA-JSON, IOTA-UL and IOTA-Manager unit test. I'll take care of it, once you complete step 1

What do you think?

[tzzed]

Great thank you! that's work, @GuillaumeOd it's in your hands.

[GuillaumeOd]

thanks @fgalan ! I just merged master to the branch. Please notice that the test I added was failing because of a type error. The expected is:

fireDetectionThreshold: { type: 'Number', value: 10 }

but for some reason we receive:

fireDetectionThreshold: { type: 'Text', value: 10 }

Is this the normal behavior ?

[fgalan]

thanks @fgalan ! I just merged master to the branch. Please notice that the test I added was failing because of a type error. The expected is:

fireDetectionThreshold: { type: 'Number', value: 10 }

but for some reason we receive:

fireDetectionThreshold: { type: 'Text', value: 10 }

Is this the normal behavior ?

Given the provision is

                            {
                                object_id: 'f_dt',
                                name: 'fireDetectionThreshold',
                                type: 'Number'
                            }

I guess that the correct one is

fireDetectionThreshold: { type: 'Number', value: 10 }

@AlvaroVega what do you think?

[AlvaroVega]

@AlvaroVega what do you think?

I think both branch and test were aligned.

[GuillaumeOd]

@AlvaroVega what do you think?

I think both branch and test were aligned.

The question is, what should be the expected payload to the test I added ? It appears that we receive a type Text but as my knowledge is limited concerning the type question in iotagent-node-lib I don't know if it should be Number for this case

[fgalan]

@AlvaroVega what do you think?

I think both branch and test were aligned.

The question is, what should be the expected payload to the test I added ? It appears that we receive a type Text but as my knowledge is limited concerning the type question in iotagent-node-lib I don't know if it should be Number for this case

It should be Number, as it is in the current test. Thus, I guess that the code needs some extra fix to align with the tests.

[GuillaumeOd]

@AlvaroVega what do you think?

I think both branch and test were aligned.

The question is, what should be the expected payload to the test I added ? It appears that we receive a type Text but as my knowledge is limited concerning the type question in iotagent-node-lib I don't know if it should be Number for this case

It should be Number, as it is in the current test. Thus, I guess that the code needs some extra fix to align with the tests.

I agree, shall I investigate it by myself ? The link with my PR is unlikely but I can try to find the fix and add it to this PR

[fgalan]

I agree, shall I investigate it by myself ? The link with my PR is unlikely but I can try to find the fix and add it to this PR

It would be great :)

not apply

[GuillaumeOd]

Hey @fgalan @AlvaroVega @tzzed,

The test was failing because the payload included a field named "t" that did not match any object_id defined in the device provisioning. As a result, the IotAgent treated "t" as an untyped attribute and defaulted its type to "Text".

However, the test expectation assumed "t" would be interpreted as psBatteryVoltage (with type: Number), which was provisioned with object_id: ".1.0.0.1". This mismatch caused the assertion failure.

To fix it, I updated the test payload to use the correct key ".1.0.0.1" instead of "t", so the attribute is properly mapped to psBatteryVoltage with the correct type.

Please tell me if the PR is ok for you now !

[AlvaroVega]

Please tell me if the PR is ok for you now !

Hey @fgalan @AlvaroVega @tzzed,

The test was failing because the payload included a field named "t" that did not match any object_id defined in the device provisioning. As a result, the IotAgent treated "t" as an untyped attribute and defaulted its type to "Text".

However, the test expectation assumed "t" would be interpreted as psBatteryVoltage (with type: Number), which was provisioned with object_id: ".1.0.0.1". This mismatch caused the assertion failure.

To fix it, I updated the test payload to use the correct key ".1.0.0.1" instead of "t", so the attribute is properly mapped to psBatteryVoltage with the correct type.

Please tell me if the PR is ok for you now !

test 021B is still failing: https://github.com/telefonicaid/iotagent-node-lib/actions/runs/15710390480/job/44269756408?pr=1667#step:5:18568

[GuillaumeOd]

Please tell me if the PR is ok for you now !

Hey @fgalan @AlvaroVega @tzzed,
The test was failing because the payload included a field named "t" that did not match any object_id defined in the device provisioning. As a result, the IotAgent treated "t" as an untyped attribute and defaulted its type to "Text".
However, the test expectation assumed "t" would be interpreted as psBatteryVoltage (with type: Number), which was provisioned with object_id: ".1.0.0.1". This mismatch caused the assertion failure.
To fix it, I updated the test payload to use the correct key ".1.0.0.1" instead of "t", so the attribute is properly mapped to psBatteryVoltage with the correct type.
Please tell me if the PR is ok for you now !

test 021B is still failing: https://github.com/telefonicaid/iotagent-node-lib/actions/runs/15710390480/job/44269756408?pr=1667#step:5:18568

My bad, I forgot to remove my old test. This should be fine now

[fgalan]

Suggested change

	- Fix attribute loss during device update when both name and object_id are defined by filtering only object_id (issue #1660)
	- Fix attribute loss during device update when both name and object_id are defined by filtering only object_id (#1660)

[GuillaumeOd]

@fgalan is it ok for you ?

[fgalan]

@GuillaumeOd we have checked that if the changes your have done in lib/services/ngsi/entities-NGSI-v2.js are reverted, the modified test doesn't break. Thus, the modification to the test are not capturing the fix done.

Thus, we propose the following:

1. Rollback the change in the existing test (in general it's always better to keep existing test as they are, so the regression set is not altered)
2. Create a new test that captures the fix you have done. That means:

• If the new test is run using the code previous to your change in lib/services/ngsi/entities-NGSI-v2.js, the test fails
• If the new test is run using the code with your change in lib/services/ngsi/entities-NGSI-v2.js, the test passes

Maybe the content in PR #1668 may be useful regarding item 2

[fgalan]

Overpassed by PR #1721