Describe the bug

When known command is registered on a nested child device (e.g. a child of a child) via MQTT, then the definition of the child device changes to an immediate child device, when the tedge-mapper-c8y service is restarted.

To Reproduce

1. Register an immediate child device

   tedge mqtt pub -r te/device/child-level1// '{"@type":"child-device","name":"child-level1"}'
   

2. Register a nested child device (from the previous child device)

   tedge mqtt pub -r te/device/child-level2// '{"@type":"child-device","name":"child-level2","@parent":"device/child-level1//"}'
   

3. Register an operation on the nested child device

   tedge mqtt pub -r te/device/child-level2///cmd/restart '{}'
   

4. Verify in Cumulocity the following device hierarchy

   graph TD
       main --> child-level1 --> child-level2
   

   Loading

5. Restart the tedge-mapper-c8y

   sudo systemctl restart tedge-mapper-c8y
   

6. Check the thin-edge.io registration message on the te/+/+/+/+ topic.

   tedge mqtt sub te/device/child-level2/+/+
   

   Notice that the '@parent' property is no longer part of the message for the nested child device.

   [te/device/child-level2//] {"@id":"ginger:device:child-level2","@type":"child-device","name":"child-level2"}
   

Expected behavior

The tedge-mapper-c8y should use the registration information on the MQTT broker over any information in the /etc/tedge/operations/c8y folder when building the entity store. This will ensure that it does not override existing registration messages with incorrect information.

Screenshots

Environment (please complete the following information):

Additional context

The root cause looks to be the mapper's interpretation of the operation files inside the /etc/tedge/operations/c8y folder which don't supported nested files.

On the first registration, the ginger:device:child-level2 folder is created under /etc/tedge/operations/c8y and the entity store knows that the ginger:device:child-level2 is a nested child devices of ginger:device:child-level1, however when the tedge-mapper-c8y is restarted, it reads the operation list, and generates registration messages which override the previous registration message.

Below is an example of the operations folder after the registration messages have been sent:

ls -l /etc/tedge/operations/c8y
total 16
-rw-r--r-- 1 tedge tedge    0 Oct 25 15:03 c8y_DownloadConfigFile
-rw-r--r-- 1 tedge tedge    0 Oct 25 15:04 c8y_LogfileRequest
-rw-r--r-- 1 tedge tedge   91 Nov  3 13:08 c8y_RemoteAccessConnect
-rw-r--r-- 1 tedge tedge    0 Oct 25 15:04 c8y_Restart
-rw-r--r-- 1 tedge tedge    0 Oct 25 15:04 c8y_SoftwareUpdate
-rw-r--r-- 1 tedge tedge    0 Oct 25 15:03 c8y_UploadConfigFile
drwxr-xr-x 2 tedge tedge 4096 Nov  3 14:19 ginger:device:child-level1
drwxr-xr-x 2 tedge tedge 4096 Nov  3 14:16 ginger:device:child-level2