registration message order

[reubenmiller]

Is your feature improvement request related to a problem? Please describe.

Registering child devices and services is often done asynchronously with all of the other messages. This can cause problems when sending the registration messages to Cumulocity as some of the telemetry data messages can be received before the registration messages which causes the cloud entity to be registered with default info (e.g. name and type) or some of the messages being silently ignored by the cloud as the device is not registered prior to receiving the message.

Describe the solution you'd like

A review needs to be done on how exactly to solve this problem reliably, but below is the order of messages that needs to be sent to Cumulocity, and there should be a brief delay (~N seconds) before any follow up messages are sent.

1. Main device (101)
2. device registration (e.g. 101)
3. Service registration (102)
4. Telemetry data or service status

Describe alternatives you've considered

Additional context

It should be noted the registration problem is mostly related to child entities (child devices and services) as the main device is registered via tedge connect c8y. This means that the main device already exists in the platform prior to the mapper being started for the first time.

System Test failures

The following flaky system test tickets are open where the suspected root cause is due to the ordering of registration messages:

• flaky system test: c8y_RequiredAvailability is set with custom value #3393
• Cumulocity operation updates fails due to MqttServiceException with message Operation with id xxx for device id yyy not found #3429